go-micro/cmd/micro

Micro

Go Micro Command Line

Install the CLI

Install micro via go install

go install go-micro.dev/v5/cmd/micro@v5.16.0

Create a service

Create your service (all setup is now automatic!):

micro new helloworld

Or use a template for common service patterns:

micro new contacts --template crud      # CRUD with Create/Read/Update/Delete/List
micro new events --template pubsub      # Pub/sub with broker integration
micro new gateway --template api        # API gateway with health check

This will:

• Create a new service in the helloworld directory
• Automatically run go mod tidy and make proto for you
• Show the updated project tree including generated files
• Warn you if protoc is not installed, with install instructions

Run the service

Run your service:

micro run

This starts:

• API Gateway on http://localhost:8080
• Web Dashboard at http://localhost:8080
• Agent Playground at http://localhost:8080/agent
• API Explorer at http://localhost:8080/api
• MCP Tools at http://localhost:8080/mcp/tools
• Hot Reload watching for file changes
• Services in dependency order

Open http://localhost:8080 to see your services and call them from the browser.

Output

  ┌─────────────────────────────────────────────────────────────┐
  │                                                             │
  │   Micro                                                     │
  │                                                             │
  │   Web:     http://localhost:8080                            │
  │   API:     http://localhost:8080/api/{service}/{method}     │
  │   Health:  http://localhost:8080/health                     │
  │                                                             │
  │   Services:                                                 │
  │     ● helloworld                                            │
  │                                                             │
  │   Watching for changes...                                   │
  │                                                             │
  └─────────────────────────────────────────────────────────────┘

Options

micro run                    # Gateway on :8080, hot reload enabled
micro run --address :3000    # Gateway on custom port
micro run --no-gateway       # Services only, no HTTP gateway
micro run --no-watch         # Disable hot reload
micro run --env production   # Use production environment
micro run github.com/micro/blog  # Clone and run from GitHub

Calling Services

Via curl:

curl -X POST http://localhost:8080/api/helloworld/Helloworld.Call -d '{"name": "World"}'

Or browse to http://localhost:8080 and use the web interface.

List services:

micro services

Configuration (micro.mu)

For multi-service projects, create a micro.mu file to define services, dependencies, and environments:

service users
    path ./users
    port 8081

service posts
    path ./posts
    port 8082
    depends users

service web
    path ./web
    port 8089
    depends users posts

env development
    STORE_ADDRESS file://./data
    DEBUG true

env production
    STORE_ADDRESS postgres://localhost/db

Configuration Options

Property	Description
path	Directory containing the service (with main.go)
port	Port the service listens on (for health checks)
depends	Services that must start first (space-separated)

Environment Management

Environment variables are injected based on the --env flag:

micro run                    # Uses 'development' env (default)
micro run --env production   # Uses 'production' env
MICRO_ENV=staging micro run  # Uses 'staging' env

JSON Alternative

You can also use micro.json if you prefer:

{
  "services": {
    "users": { "path": "./users", "port": 8081 },
    "posts": { "path": "./posts", "port": 8082, "depends": ["users"] }
  },
  "env": {
    "development": { "STORE_ADDRESS": "file://./data" }
  }
}

Without Configuration

If no micro.mu or micro.json exists, micro run discovers all main.go files and runs them (original behavior).

Describe the service

Describe the service to see available endpoints

micro describe helloworld

Output

{
    "name": "helloworld",
    "version": "latest",
    "metadata": null,
    "endpoints": [
        {
            "request": {
                "name": "Request",
                "type": "Request",
                "values": [
                    {
                        "name": "name",
                        "type": "string",
                        "values": null
                    }
                ]
            },
            "response": {
                "name": "Response",
                "type": "Response",
                "values": [
                    {
                        "name": "msg",
                        "type": "string",
                        "values": null
                    }
                ]
            },
            "metadata": {},
            "name": "Helloworld.Call"
        },
        {
            "request": {
                "name": "Context",
                "type": "Context",
                "values": null
            },
            "response": {
                "name": "Stream",
                "type": "Stream",
                "values": null
            },
            "metadata": {
                "stream": "true"
            },
            "name": "Helloworld.Stream"
        }
    ],
    "nodes": [
        {
            "metadata": {
                "broker": "http",
                "protocol": "mucp",
                "registry": "mdns",
                "server": "mucp",
                "transport": "http"
            },
            "id": "helloworld-31e55be7-ac83-4810-89c8-a6192fb3ae83",
            "address": "127.0.0.1:39963"
        }
    ]
}

Call the service

Call via RPC endpoint

micro call helloworld Helloworld.Call '{"name": "Asim"}'

Create a client

Create a client to call the service

package main

import (
        "context"
        "fmt"

        "go-micro.dev/v5"
)

type Request struct {
        Name string
}

type Response struct {
        Message string
}

func main() {
        client := micro.New("helloworld").Client()

        req := client.NewRequest("helloworld", "Helloworld.Call", &Request{Name: "John"})

        var rsp Response

        err := client.Call(context.TODO(), req, &rsp)
        if err != nil {
                fmt.Println(err)
                return
        }

        fmt.Println(rsp.Message)
}

Building and Deployment

Build Binaries

Build Go binaries for deployment:

micro build                     # Build for current OS
micro build --os linux          # Cross-compile for Linux
micro build --os linux --arch arm64  # For ARM64
micro build --output ./dist     # Custom output directory

Deploy to Server

Deploy to any Linux server with systemd:

# First time: set up the server
ssh user@server
curl -fsSL https://go-micro.dev/install.sh | sh
sudo micro init --server
exit

# Deploy from your laptop
micro deploy user@server

The deploy command:

1. Builds binaries for linux/amd64
2. Copies via SSH to /opt/micro/bin/
3. Sets up systemd services (micro@<service>)
4. Restarts and verifies services are running

Named Deploy Targets

Add deploy targets to micro.mu:

deploy prod
    ssh deploy@prod.example.com

deploy staging
    ssh deploy@staging.example.com

Then:

micro deploy prod      # Deploy to production
micro deploy staging   # Deploy to staging

Managing Deployed Services

# Check status
micro status --remote user@server

# View logs
micro logs --remote user@server
micro logs myservice --remote user@server -f

# Stop a service
micro stop myservice --remote user@server

See internal/website/docs/deployment.md for the full deployment guide.

API Gateway

Run a standalone HTTP-to-RPC gateway (no dashboard, no auth, no hot reload):

micro api                    # listen on :8080
micro api --address :3000    # custom port

Routes:

• POST /{service}/{endpoint} — proxies to an RPC call
• GET / — lists all services and endpoints
• GET /{service} — describes a service
• GET /health — health check

curl -XPOST -d '{"name":"Alice"}' http://localhost:8080/greeter/Greeter.Hello

Inspecting the Framework

Every core interface has a matching CLI command:

Registry

micro registry list              # list all registered services (JSON)
micro registry get <name>        # show nodes and endpoints for a service
micro registry watch             # stream registration events

Broker

micro broker publish <topic> <message>   # publish a message
micro broker subscribe <topic>           # stream messages from a topic

Store

micro store list [prefix]        # list keys (optionally by prefix)
micro store read <key>           # read a record
micro store write <key> <value>  # write a record
micro store delete <key>         # delete a record

Config

micro config get <key>           # read a config value (dot notation → env var)
micro config dump                # print all configuration

Keys use dot notation: database.host reads from DATABASE_HOST.

AI & Agents

micro chat

Interactive LLM agent that discovers services and orchestrates them through natural language:

ANTHROPIC_API_KEY=sk-ant-... micro chat --provider anthropic
> list all users
> send a welcome email to Alice

Supports: --provider (anthropic, openai, gemini, atlascloud, groq, mistral, together), --prompt for single-shot mode, --model and --base_url for overrides.

Environment variables: MICRO_AI_PROVIDER, MICRO_AI_API_KEY, or provider-specific keys like ANTHROPIC_API_KEY.

micro flow

Event-driven LLM orchestration:

# Subscribe to events and react
micro flow run --trigger events.user.created \
  --prompt "New user: {{.Data}}. Send welcome email." \
  --provider anthropic

# One-shot execution
micro flow exec --prompt "List all users" --provider anthropic

micro mcp

Expose services as MCP tools for AI agents:

micro mcp serve              # stdio transport (for Claude Code)
micro mcp serve --address :3000  # HTTP/SSE transport
micro mcp list               # list available tools
micro mcp test <tool>        # test a tool

Protobuf

Use protobuf for code generation with protoc-gen-micro

Server

The micro server is a production web dashboard and authenticated API gateway for interacting with services that are already running (e.g., managed by systemd via micro deploy). It does not build, run, or watch services — for local development, use micro run instead.

Run it like so

micro server

Then browse to localhost:8080 and log in with the default admin account (admin/micro).

API Endpoints

The API provides a fixed HTTP entrypoint for calling services

curl http://localhost:8080/api/helloworld/Helloworld/Call -d '{"name": "John"}'

See /api for more details and documentation for each service

Web Dashboard

The web dashboard provides a modern, secure UI for managing and exploring your Micro services. Major features include:

• Dynamic Service & Endpoint Forms: Browse all registered services and endpoints. For each endpoint, a dynamic form is generated for easy testing and exploration.
• API Documentation: The /api page lists all available services and endpoints, with request/response schemas and a sidebar for quick navigation. A documentation banner explains authentication requirements.
• JWT Authentication: All login and token management uses a custom JWT utility. Passwords are securely stored with bcrypt. All /api/x endpoints and authenticated pages require an Authorization: Bearer <token> header (or micro_token cookie as fallback).
• Token Management: The /auth/tokens page allows you to generate, view (obfuscated), and copy JWT tokens. Tokens are stored and can be revoked. When a user is deleted, all their tokens are revoked immediately.
• User Management: The /auth/users page allows you to create, list, and delete users. Passwords are never shown or stored in plaintext.
• Token Revocation: JWT tokens are stored and checked for revocation on every request. Revoked or deleted tokens are immediately invalidated.
• Security: All protected endpoints use consistent authentication logic. Unauthorized or revoked tokens receive a 401 error. All sensitive actions require authentication.
• Logs & Status: View service logs and status (PID, uptime, etc) directly from the dashboard.

To get started, run:

micro server

Then browse to localhost:8080 and log in with the default admin account (admin/micro).

Note: See the /api page for details on API authentication and how to generate tokens for use with the HTTP API

Gateway Architecture

The micro run and micro server commands both use a unified gateway implementation (cmd/micro/server/gateway.go), providing consistent HTTP-to-RPC translation, service discovery, and web UI capabilities.

Key Differences

Feature	micro run	micro server
Purpose	Development	Production
Authentication	Enabled (default admin/micro)	Enabled (default admin/micro)
Process Management	Yes (builds/runs services)	No (assumes services running)
Hot Reload	Yes (watches files)	No
Scopes	Available (/auth/scopes)	Available (/auth/scopes)
Use Case	Local development	Deployed API gateway

Why Unified?

Previously, each command had its own gateway implementation, leading to code duplication. The unified gateway means:

• New features (like MCP integration) benefit both commands
• Consistent behavior between development and production
• Single codebase to test and maintain
• Same HTTP API, web UI, and service discovery logic

Gateway Features

Both commands provide:

• HTTP API: POST /api/{service}/{endpoint} with JSON request/response
• Service Discovery: Automatic detection via registry (mdns/consul/etcd)
• Health Checks: /health, /health/live, /health/ready endpoints
• Web Dashboard: Browse services, test endpoints, view documentation
• Hot Service Updates: Gateway automatically picks up new service registrations
• JWT Authentication: Tokens, user management, login at /auth/login, /auth/tokens, /auth/users
• Endpoint Scopes: Restrict which tokens can call which endpoints via /auth/scopes
• MCP Integration: AI tools at /mcp/tools, agent playground at /agent

Authentication & Scopes

Both micro run and micro server use the same auth.Account type from the go-micro framework. The gateway stores accounts under auth/<id> in the default store and uses JWT tokens with RSA256 signing.

Scope enforcement applies to all call paths:

Path	Description
POST /api/{service}/{endpoint}	HTTP API calls
POST /mcp/call	MCP tool invocations
Agent playground	Tool calls made by the AI agent

Scopes are configured via the web UI at /auth/scopes. Each endpoint can require one or more scopes. A token must carry at least one matching scope to call a protected endpoint. The * scope on a token bypasses all checks. Endpoints with no scopes set are open to any authenticated token.

See the Scopes section below for details.

Development Mode (micro run)

micro run  # Auth enabled, default admin/micro

• Authentication enabled with default credentials (admin/micro)
• Web UI requires login
• Scopes available for testing access control
• Ideal for development with realistic auth behavior

Production Mode (micro server)

micro server  # Auth enabled, JWT tokens required

• JWT authentication on all API calls
• User/token management via web UI
• Secure by default
• Login required: default credentials admin/micro

Programmatic Gateway Usage

You can also start the gateway programmatically in your own Go code:

import "go-micro.dev/v5/cmd/micro/server"

// Start gateway with auth (recommended)
gw, err := server.StartGateway(server.GatewayOptions{
    Address:     ":8080",
    AuthEnabled: true,
})

// Start gateway without auth (testing only)
gw, err := server.StartGateway(server.GatewayOptions{
    Address:     ":8080",
    AuthEnabled: false,
})

See internal/website/docs/architecture/adr-010-unified-gateway.md for architecture details.

Scopes

Scopes provide fine-grained access control over which tokens can call which service endpoints. They are managed through the web UI at /auth/scopes and enforced on every call through the gateway.

How It Works

1. Define scopes on endpoints — Visit /auth/scopes and set required scopes for each service endpoint (e.g., set billing on payments.Payments.Charge)
2. Create tokens with scopes — Visit /auth/tokens and create tokens with matching scopes (e.g., a token with billing scope)
3. Scopes are enforced — When a token calls an endpoint, the gateway checks that the token has at least one scope matching the endpoint's required scopes

Scope Matching Rules

• Scopes are exact string matches — billing on a token matches billing on an endpoint
• A token with * scope bypasses all scope checks (admin wildcard)
• Endpoints with no scopes set are open to any valid token
• An endpoint can require multiple scopes — the token needs to match just one
• Scope names are free-form strings — use whatever convention fits your project

Common Patterns

Pattern	Endpoint Scopes	Token Scopes	Result
Protect a service	Set greeter on all greeter endpoints (use Bulk Set with greeter.*)	Token with greeter	Token can call any greeter endpoint
Restrict an endpoint	Set billing on payments.Payments.Charge	Token with billing	Only that endpoint is restricted
Role-based	Set admin on sensitive endpoints	Admin token with admin, user token with user	Only admin tokens can call sensitive endpoints
Full access	Any	Token with *	Bypasses all scope checks

Relationship to Framework Auth

The gateway's scope system uses auth.Account from the go-micro framework. Scopes on accounts are the same []string field used by the framework's auth.Rules and wrapper/auth package. The gateway stores scope requirements in the default store under endpoint-scopes/<service>.<endpoint> keys and checks them on every HTTP request.

For service-level (RPC) auth within the go-micro mesh, use the wrapper/auth package which provides auth.Rules with priority-based access control. See the auth wrapper documentation for details.