Service Deployer

New microservices are deployed into the running platform by magicvarsh-infra-service via the Infrastructure → Deploy Service screen. It can deploy from a Docker image or, more commonly, by uploading a Spring Boot fat-JAR — the system builds a Docker image from the JAR, starts the container, and registers the service so the gateway, log viewer and API docs pick it up.

Strict rules — creating the service

1. Build a Spring Boot executable (fat) JAR with an embedded Eureka client — the deployer waits for the service to register with Eureka.
2. Set spring.application.name. It is used as the service name and to derive the gateway slug (the name with a trailing -service removed, lower-cased), so it must be unique.
3. Configure server.port (or let the deployer auto-read it). Internal ports stay on the Docker network; never expose the service directly to the host.
4. Give the service its own database schema with Flyway migrations under src/main/resources/db/migration/V*.sql.
5. Rely on the gateway for auth: read the forwarded X-User-* headers; do not re-validate the JWT in the service.

Strict rules — deploying a JAR

1. Open Infrastructure and select the Deploy Service tab.
2. Choose the JAR File (.jar, required) — a Spring Boot executable JAR with an embedded Eureka client.
3. Service Name (optional) — leave blank to auto-read from spring.application.name.
4. Port (optional) — leave blank to auto-read from server.port.
5. Dashboard Group — defaults to magic-varsh.
6. Add any Environment Variables (sent as ENV_* parameters).
7. Select Deploy JAR and wait — building the image and starting the container can take up to two minutes on the first deploy. The service then registers with Eureka automatically.

Deploying from a Docker image

Alternatively, deploy a prebuilt image. The request carries the service name, image, port, hostPort, environment variables and a description.

POST /api/infra/deploy/jar     # multipart: file, serviceName?, port?, group, ENV_*
POST /api/infra/deploy         # JSON: name, image, port, hostPort, envVars, description

Strict rules — scaling & undeploying

• Scaling: scale up/down from the Instances view (POST /api/infra/services/{name}/scale). You cannot scale below 1 instance.
• Undeploy: only dynamically deployed JAR services can be undeployed (DELETE /api/infra/services/{name}). The core, statically defined services are protected and cannot be removed this way.