micro--go-micro
96280678ee
* feat: expose framework primitives via API gateway and MCP
Add registry, store, and broker as both HTTP routes and MCP tools
so AI agents and HTTP clients can inspect and operate the framework.
API gateway (/micro/* namespace):
GET /micro/registry List registered services
GET /micro/registry/{name} Describe a service
GET /micro/store List store keys
GET /micro/store/{key} Read a record
POST /micro/store/{key} Write a record
POST /micro/broker/{topic} Publish a message
MCP gateway (micro_* tool prefix):
micro_registry_list List services
micro_registry_get Describe a service
micro_store_list List keys
micro_store_read Read a record
micro_store_write Write a record
micro_broker_publish Publish a message
Framework tools use a Handler field on the MCP Tool struct for
direct dispatch (no RPC). Service tools continue to use RPC.
Rate limiters and circuit breakers are applied to framework
tools the same as service tools.
* fix: make framework internals opt-in on API and MCP gateways
Framework primitives (registry, broker, store) are now only
exposed when explicitly enabled:
API gateway: micro api --internal
MCP gateway: Options{Internal: true}
Off by default — user services are always exposed, framework
internals require the flag. Banner output only shows framework
routes when enabled.
* fix: always expose framework internals, gate by auth in production
Revert the --internal flag approach. Framework primitives (registry,
broker, store) are now always exposed:
- micro api: /micro/* routes always available (dev tool)
- MCP gateway: micro_* tools always registered. When Auth is
configured (production), they require micro:admin scope.
Without Auth (dev), they're open — same as all other tools.
This follows the existing pattern: micro run/api = dev (open),
micro server = production (auth + scopes). Framework internals
follow the same security model as user services.
Remove the Internal option from MCP Options. Remove --internal
flag from micro api.
Note: scope persistence depends on the store backend. The default
in-memory store does not survive restarts. Use MICRO_STORE=file
for persistent scopes in production.
* fix: correct DefaultStore comment — it's file-backed, not memory
* fix(server): don't recreate deleted admin user on restart
When the default admin account is deleted via the dashboard, set
a marker key (auth/.admin-deleted) in the store. On startup, skip
admin creation if the marker exists. This prevents the default
admin/micro credentials from reappearing after restart when the
user has intentionally removed them.
* fix: improve agent playground first-run UX and fix doc 404s
Agent playground:
- Add setup hint in empty state explaining how to get started
(click Settings, enter API key, type a prompt)
- Hide hint automatically when API key is already configured
- Add all 7 providers to dropdown (was only OpenAI + Anthropic)
- Include CLI fallback suggestion (micro chat)
Docs:
- Fix .md links to .html across all doc pages — Jekyll serves
.html files, not .md. Fixes 404s including the micro run guide.
---------
Co-authored-by: Claude <noreply@anthropic.com>
4.6 KiB
4.6 KiB
layout
| layout |
|---|
| default |
Configuration
Go Micro follows a progressive configuration model so you can start with zero setup and layer in complexity only when needed.
Levels of Configuration
- Zero Config (Defaults)
- mDNS registry, HTTP transport, in-memory broker/store
- Environment Variables
- Override core components without code changes
- Code Options
- Fine-grained control via functional options
- External Sources (Future / Plugins)
- Configuration loaded from files, vaults, or remote services
Core Environment Variables
| Component | Variable | Example | Purpose |
|---|---|---|---|
| Registry | MICRO_REGISTRY |
MICRO_REGISTRY=consul |
Select registry implementation |
| Registry Address | MICRO_REGISTRY_ADDRESS |
MICRO_REGISTRY_ADDRESS=127.0.0.1:8500 |
Point to registry service |
| Broker | MICRO_BROKER |
MICRO_BROKER=nats |
Select broker implementation |
| Broker Address | MICRO_BROKER_ADDRESS |
MICRO_BROKER_ADDRESS=nats://localhost:4222 |
Broker endpoint |
| Transport | MICRO_TRANSPORT |
MICRO_TRANSPORT=nats |
Select transport implementation |
| Transport Address | MICRO_TRANSPORT_ADDRESS |
MICRO_TRANSPORT_ADDRESS=nats://localhost:4222 |
Transport endpoint |
| Store | MICRO_STORE |
MICRO_STORE=postgres |
Select store implementation |
| Store Database | MICRO_STORE_DATABASE |
MICRO_STORE_DATABASE=app |
Logical database name |
| Store Table | MICRO_STORE_TABLE |
MICRO_STORE_TABLE=records |
Default table/collection |
| Store Address | MICRO_STORE_ADDRESS |
MICRO_STORE_ADDRESS=postgres://user:pass@localhost:5432/app?sslmode=disable |
Connection string |
| Server Address | MICRO_SERVER_ADDRESS |
MICRO_SERVER_ADDRESS=:8080 |
Bind address for RPC server |
Example: Switching Components via Env Vars
# Use NATS for broker and transport, Consul for registry
export MICRO_BROKER=nats
export MICRO_TRANSPORT=nats
export MICRO_REGISTRY=consul
export MICRO_REGISTRY_ADDRESS=127.0.0.1:8500
# Run your service
go run main.go
No code changes required. The framework internally wires the selected implementations.
Equivalent Code Configuration
service := micro.NewService(
micro.Name("helloworld"),
micro.Broker(nats.NewBroker()),
micro.Transport(natstransport.NewTransport()),
micro.Registry(consul.NewRegistry(registry.Addrs("127.0.0.1:8500"))),
)
service.Init()
Use env vars for deployment level overrides; use code options for explicit control or when composing advanced setups.
Precedence Rules
- Explicit code options always win
- If not set in code, env vars are applied
- If neither code nor env vars set, defaults are used
Discoverability Strategy
Defaults allow local development with zero friction. As teams scale:
- Introduce env vars for staging/production parity
- Consolidate secrets (e.g. store passwords) using external secret managers (future guide)
- Move to service mesh aware registry (Consul/NATS JetStream)
Validating Configuration
Enable debug logging to confirm selected components:
MICRO_LOG_LEVEL=debug go run main.go
You will see lines like:
Registry [consul] Initialised
Broker [nats] Connected
Transport [nats] Listening on nats://localhost:4222
Store [postgres] Connected to app/records
Patterns
Twelve-Factor Alignment
Environment variables map directly to deploy-time configuration. Avoid hardcoding component choices so services remain portable.
Multi-Environment Setup
Use a simple env file per environment:
# .env.staging
MICRO_REGISTRY=consul
MICRO_REGISTRY_ADDRESS=consul.staging.internal:8500
MICRO_BROKER=nats
MICRO_BROKER_ADDRESS=nats.staging.internal:4222
MICRO_STORE=postgres
MICRO_STORE_ADDRESS=postgres://staging:pass@pg.staging.internal:5432/app?sslmode=disable
Load with your process manager or container orchestrator.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| Service starts with memory store unexpectedly | Env vars not exported | `env |
| Consul errors about connection refused | Wrong address/port | Check MICRO_REGISTRY_ADDRESS value |
| NATS connection timeout | Server not running | Start NATS or change address |
| Postgres SSL errors | Missing sslmode param | Append ?sslmode=disable locally |