cmd/micro/README.md
Go Micro Command Line
Install micro via go install
go install go-micro.dev/v5/cmd/[email protected]
Create your service (all setup is now automatic!):
micro new helloworld
This will:
helloworld directorygo mod tidy and make proto for youprotoc is not installed, with install instructionsRun your service:
micro run
This starts:
Open http://localhost:8080 to see your services and call them from the browser.
┌─────────────────────────────────────────────────────────────┐
│ │
│ Micro │
│ │
│ Web: http://localhost:8080 │
│ API: http://localhost:8080/api/{service}/{method} │
│ Health: http://localhost:8080/health │
│ │
│ Services: │
│ ● helloworld │
│ │
│ Watching for changes... │
│ │
└─────────────────────────────────────────────────────────────┘
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
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
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
| 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 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
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" }
}
}
If no micro.mu or micro.json exists, micro run discovers all main.go files and runs them (original behavior).
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 via RPC endpoint
micro call helloworld Helloworld.Call '{"name": "Asim"}'
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)
}
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 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:
/opt/micro/bin/micro@<service>)Add deploy targets to micro.mu:
deploy prod
ssh [email protected]
deploy staging
ssh [email protected]
Then:
micro deploy prod # Deploy to production
micro deploy staging # Deploy to staging
# 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.
Use protobuf for code generation with protoc-gen-micro
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).
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
The web dashboard provides a modern, secure UI for managing and exploring your Micro services. Major features include:
/api page lists all available services and endpoints, with request/response schemas and a sidebar for quick navigation. A documentation banner explains authentication requirements./api/x endpoints and authenticated pages require an Authorization: Bearer <token> header (or micro_token cookie as fallback)./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./auth/users page allows you to create, list, and delete users. Passwords are never shown or stored in plaintext.To get started, run:
micro server
Then browse to localhost:8080 and log in with the default admin account (admin/micro).
Note: See the
/apipage for details on API authentication and how to generate tokens for use with the HTTP API
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.
| 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 |
Previously, each command had its own gateway implementation, leading to code duplication. The unified gateway means:
Both commands provide:
POST /api/{service}/{endpoint} with JSON request/response/health, /health/live, /health/ready endpoints/auth/login, /auth/tokens, /auth/users/auth/scopes/api/mcp/tools, agent playground at /agentBoth 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 /api/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.
micro run)micro run # Auth enabled, default admin/micro
admin/micro)micro server)micro server # Auth enabled, JWT tokens required
admin/microYou 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 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.
/auth/scopes and set required scopes for each service endpoint (e.g., set billing on payments.Payments.Charge)/auth/tokens and create tokens with matching scopes (e.g., a token with billing scope)billing on a token matches billing on an endpoint* scope bypasses all scope checks (admin wildcard)| 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 |
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.