Mastering Microservices Deployment

Deploying a microservice well means more than getting a container to start. You need a repeatable build, a place to run it, automatic deploys, a database, a way in from the internet and monitoring that tells you when something breaks. This guide is the roadmap for deploying one service, a user authentication service, on your own Linux server with Docker and Kubernetes, and links to the step-by-step guides for each stage.

1. The stack in 2026

The original version of this guide listed a long chain of tools on CentOS. CentOS Linux has reached end of life, and several of those tools overlap. A leaner, current stack:

Separate API gateways (Kong) and load balancers (HAProxy) are useful at scale but not needed for your first service: the Ingress controller already routes traffic and balances it across pods. Add a gateway when you have many services that share authentication, rate limits or API keys.

2. Build the service to be deployable

Whatever the language, a service that runs well in containers:

• reads its settings (database URL, secrets, port) from environment variables;
• listens on 0.0.0.0 and the port it's told to use;
• logs to standard output, not to files;
• exposes a health endpoint, such as /healthz, that returns 200 when it can serve requests;
• stops cleanly when it receives SIGTERM.

The user authentication service itself is built in Developing the user authentication service.

3. Containerise it with Docker

Write a multi-stage Dockerfile that runs as a non-root user, add a .dockerignore, then build, run and test the image locally:

docker build -t ghcr.io/yourorg/user-service:1.0.0 .
docker run --rm -p 3000:3000 --env-file .env ghcr.io/yourorg/user-service:1.0.0
curl -i http://localhost:3000/healthz
docker push ghcr.io/yourorg/user-service:1.0.0

Tag images with a version or the Git commit, never only latest, so you always know what is running and can roll back. The full walkthrough is Containerising the user service with Docker.

4. Run it on Kubernetes

On a single server, k3s installs a complete, certified Kubernetes in a few minutes. Your service needs three objects: a Deployment (the pods), a Service (a stable internal address) and an Ingress (the public hostname).

A minimal Deployment with health checks and resource limits:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 2
  selector:
    matchLabels: { app: user-service }
  template:
    metadata:
      labels: { app: user-service }
    spec:
      containers:
        - name: user-service
          image: ghcr.io/yourorg/user-service:1.0.0
          ports: [{ containerPort: 3000 }]
          envFrom: [{ secretRef: { name: user-service-env } }]
          readinessProbe:
            httpGet: { path: /healthz, port: 3000 }
          livenessProbe:
            httpGet: { path: /healthz, port: 3000 }
            initialDelaySeconds: 10
          resources:
            requests: { cpu: 100m, memory: 128Mi }
            limits: { memory: 256Mi }

Keep secrets in a Kubernetes Secret (created from your CI or with a tool such as Sealed Secrets or External Secrets), never in the image or the Git repository. The Service, Ingress and rollout commands are in Deploying the user service with Kubernetes.

5. Package it with Helm

Once the YAML works, turn it into a Helm chart so the same templates deploy to staging and production with different values (image tag, replicas, hostname, resources):

helm upgrade --install user-service ./charts/user-service \
  --namespace auth --create-namespace \
  --set image.tag=1.0.1

helm rollback user-service returns to the previous release. See Helm charts for beginners.

6. Automate deploys with CI/CD

A pipeline should run on every merge to your main branch:

GitHub Actions is the simplest option for code already on GitHub; see GitHub Actions CI/CD to a VPS. Jenkins still works if your team already runs it.

7. The database

An authentication service holds user accounts, so treat its data with care:

• Managed database: the least work. Your cluster connects to it over TLS.
• In the cluster: run PostgreSQL or MongoDB as a StatefulSet with a persistent volume, or with an operator. You own backups and upgrades.

Either way, schedule backups, copy them off the server and test a restore. Hash passwords with Argon2 or bcrypt, and never log tokens or passwords. Choosing between PostgreSQL, MySQL, SQLite and MongoDB helps you pick.

8. Monitoring, logs and the Rancher dashboard

Install the Prometheus and Grafana stack (the kube-prometheus-stack Helm chart is the usual route) and expose a /metrics endpoint from your service. Watch request rate, error rate and latency, and alert on them. Add Loki to search logs from every pod in one place. The setup is in Production observability with Prometheus, Grafana and Loki.

Rancher adds a web dashboard for scaling, rolling out and reading logs without kubectl. It is optional and uses extra memory; see Managing the deployment with Rancher.

9. Where to run this on Domain India

Kubernetes, Docker and Rancher need root access and kernel features that shared hosting doesn't allow, so they can't run on cPanel, DirectAdmin or Webuzo plans.

• VPS: Domain India VPS plans are self-managed KVM servers with full root access. You install and look after the operating system, k3s and your services. A 4 GB plan suits k3s with a few small services; add Rancher and the monitoring stack and choose 8 GB or more.
• App Platform: if you don't want to run Kubernetes at all, the App Platform builds and runs your service for you. Node.js apps are detected automatically; other languages build from your Dockerfile. It includes PostgreSQL. See Getting started with the App Platform.

Card prices are Domain India list prices on 19 September 2026, excluding 18% GST.

Frequently asked questions

Ready to deploy your service? Start with containerising it with Docker, then compare VPS plans and the App Platform, or open a support ticket if you're unsure which fits.