Skip to content

Deployment Guide

A J7M deployment has at least a host process and its application artifacts. Network discovery, invocation transports, artifact distribution and durable resource groups can run in separate processes. Select those boundaries from the application's availability and operational needs, rather than assuming every concern belongs in one JVM.

Runtime and application topology

Open full-size SVG. On small screens, scroll the diagram horizontally.

Follow this sequence:

  1. Build and inspect the artifacts.
  2. Choose process and host boundaries.
  3. Establish application signing and repository trust.
  4. Configure reachable endpoints and durable storage.
  5. Integrate with the process/container supervisor.
  6. Define readiness and graceful shutdown.
  7. Verify the deployed topology from another process.

Application discovery and consensus membership are independent. A newly discovered service can become a candidate for future calls; it does not become a voter or acquire authority over durable state. Similarly, repository publication makes a verified artifact available but does not prove that an application has been activated.

The examples use the current APIs and immutable application coordinates. There is no required J7M-specific Kubernetes operator or universal application-server XML file. Host assembly is explicit Java configuration, application declarations use the actual JSON manifest, and optional deployment tooling consumes those contracts.

Release operations