Older documentation. Start with the current guides.

Hosting Go Micro Services

Go Micro services are compiled Go binaries that communicate via RPC and event-driven messaging. Hosting them requires infrastructure that supports service discovery, inter-service communication, persistent storage, and configuration management. Because go-micro uses a pluggable architecture, the hosting environment can range from a single VPS to a fully orchestrated cluster.

Current Hosting Options

Single VPS or Bare Metal

The simplest approach. Deploy compiled binaries to a Linux server and manage them with systemd. This is the model described in the Deployment Guide.

Good for: Small teams, early-stage projects, predictable workloads.

Server
├── micro@users.service
├── micro@posts.service
├── micro@web.service
└── mdns for discovery

Use micro deploy to push binaries over SSH
systemd handles process supervision and restarts
mDNS provides zero-configuration service discovery on the local host
Environment files supply per-service configuration

Multiple Servers

Run services across several machines. This requires replacing mDNS with a network-aware registry like Consul or Etcd so services can discover each other across hosts.

# Point all services at a shared registry
MICRO_REGISTRY=consul MICRO_REGISTRY_ADDRESS=consul.internal:8500

Deploy with micro deploy to each target server
Use a central registry (Consul, Etcd, or NATS) for cross-host discovery
Place a load balancer or API gateway in front of public-facing services

Containers and Kubernetes

Package each service as a Docker image and deploy to a Kubernetes cluster or a simpler container runtime like Docker Compose.

Dockerfile example:

FROM golang:1.21-alpine AS build
WORKDIR /app
COPY . .
RUN go build -o service ./cmd/service

FROM alpine:3.19
COPY --from=build /app/service /service
ENTRYPOINT ["/service"]

Kubernetes considerations:

Use the Kubernetes registry plugin or run Consul/Etcd as a StatefulSet
ConfigMaps and Secrets replace environment files
Kubernetes Services and Ingress handle external traffic
Horizontal Pod Autoscaler manages scaling
Liveness and readiness probes map to go-micro health checks

Platform as a Service (PaaS)

Deploy to managed platforms like Railway, Render, or Fly.io. Each service runs as a separate application.

Configuration via platform-provided environment variables
Managed TLS and load balancing out of the box
Use NATS or a hosted registry for service discovery between apps
Limited control over networking and co-location

What a Hosting Platform Needs

A purpose-built platform for go-micro services would integrate with the framework’s core abstractions rather than treating services as generic containers.

Service Discovery

The platform must run or integrate with a supported registry so services find each other automatically.

Environment	Recommended Registry
Single host	mDNS (default, zero config)
Multi-host / cloud	Consul, Etcd, or NATS
Kubernetes	Kubernetes registry plugin

RPC and Messaging

Services communicate over RPC (request/response) and asynchronous messaging (pub/sub). The platform must allow direct service-to-service communication on the configured transport.

Transport: HTTP (default), gRPC, or NATS
Broker: HTTP event broker (default), NATS, or RabbitMQ
Internal traffic should stay on a private network
External traffic flows through a gateway or load balancer

Configuration Management

Each service loads configuration from environment variables, files, or remote sources. The platform should provide:

Per-service environment variables or config files
Secret management with restricted access
Hot-reload support for dynamic configuration changes

Data Storage

go-micro’s store interface supports multiple backends. The platform should provide or connect to durable storage.

Development: In-memory store (default)
Production: Postgres, MySQL, Redis, or other supported backends
Persistent volumes or managed database services for stateful data

Health Checks and Observability

The platform should monitor service health and provide visibility into behavior.

Health endpoints for liveness and readiness
Structured logs collected and searchable
Metrics (request rates, latencies, error rates) scraped or pushed
Distributed tracing across service boundaries

See Observability for details on logs, metrics, and traces.

Security

TLS for all inter-service communication
Service-level authentication and authorization via go-micro’s auth interface
Network isolation between services and the public internet
Secret rotation and audit logging

Scaling

Horizontal scaling: run multiple instances of a service behind the client-side load balancer
The registry tracks all instances; the selector distributes requests
Auto-scaling based on resource usage or request volume

Ideal Platform Architecture

A hosting platform tailored for go-micro would look like this:

                    ┌──────────────┐
    Internet ──────▶│   Gateway    │
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
        ┌─────▼────┐ ┌────▼─────┐ ┌───▼──────┐
        │ Service A │ │ Service B│ │ Service C │
        │ (n inst.) │ │ (n inst.)│ │ (n inst.) │
        └─────┬────┘ └────┬─────┘ └───┬──────┘
              │            │            │
    ┌─────────▼────────────▼────────────▼─────────┐
    │              Private Network                 │
    │  ┌──────────┐  ┌───────┐  ┌──────────────┐  │
    │  │ Registry │  │ Broker│  │   Store      │  │
    │  │(Consul/  │  │(NATS/ │  │(Postgres/    │  │
    │  │ Etcd)    │  │ Redis)│  │ MySQL/Redis) │  │
    │  └──────────┘  └───────┘  └──────────────┘  │
    └─────────────────────────────────────────────┘

Platform Capabilities

Deploy — Push binaries or container images; the platform registers them with the registry
Discover — Built-in registry so services find each other without manual configuration
Route — Gateway for external traffic; direct RPC for internal traffic
Scale — Add or remove instances; the registry and selector handle rebalancing
Configure — Environment variables, secrets, and dynamic config per service
Observe — Centralized logs, metrics dashboards, and trace visualization
Secure — Automatic TLS, service identity, and network policies

Deployment Workflow

Developer                        Platform
────────                        ────────
micro build           ─────▶   Receive binary/image
micro deploy prod     ─────▶   Place on compute
                               Register with discovery
                               Start health checks
                               Route traffic

Choosing a Hosting Strategy

Factor	Single VPS	Multi-Server	Kubernetes	PaaS
Complexity	Low	Medium	High	Low
Cost	Low	Medium	High	Variable
Scaling	Manual	Manual	Automatic	Automatic
Service discovery	mDNS	Consul/Etcd/NATS	Plugin or Consul	External
Ops overhead	Minimal	Moderate	Significant	Minimal
Best for	Prototypes, small apps	Growing teams	Large-scale production	Quick launches

Getting Started

Start simple — Deploy to a single server with micro deploy and mDNS
Add a registry — When you need multiple servers, switch to Consul or Etcd
Containerize — When you need reproducible environments, add Docker
Orchestrate — When you need auto-scaling and self-healing, move to Kubernetes or a PaaS

Deployment — Deploy services to a Linux server with systemd
Registry — Service discovery backends
Architecture — Go Micro design and components
Observability — Logs, metrics, and tracing
Performance — Performance characteristics and tuning