micro--go-micro
Asim Aslam
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>
3.0 KiB
3.0 KiB
layout
| layout |
|---|
| default |
Micro Server (Optional)
The Micro server is an optional web dashboard and authenticated API gateway for production environments. It provides a secure entrypoint for discovering and interacting with services that are already running (e.g., managed by systemd via micro deploy).
micro server does not build, run, or watch services. It only discovers services via the registry and provides a UI/API to interact with them.
micro server vs micro run
micro run |
micro server |
|
|---|---|---|
| Purpose | Local development | Production dashboard |
| Builds services | Yes | No |
| Runs services | Yes (as child processes) | No (discovers already-running services) |
| Hot reload | Yes | No |
| Authentication | Yes (default admin/micro) |
Yes (default admin/micro) |
| Scopes | Yes (/auth/scopes) |
Yes (/auth/scopes) |
| Dashboard | Full gateway UI with auth, scopes, agent | Full dashboard with API explorer, logs, user/token management |
| When to use | Day-to-day development | Deployed environments, shared servers |
For local development, use micro run instead.
Install
Install the CLI which includes the server command:
go install go-micro.dev/v5/cmd/micro@v5.16.0
Note: Use a specific version instead of
@latestto avoid module path conflicts. See releases for the latest version.
Run
Start the server:
micro server
Then open http://localhost:8080 and log in with the default admin account (admin/micro).
Features
- Web Dashboard — Browse registered services, view endpoints, request/response schemas
- API Gateway — Authenticated HTTP-to-RPC proxy at
/api/{service}/{method} - JWT Authentication — All API endpoints require a Bearer token or session cookie
- Token Management — Generate, view, copy, and revoke JWT tokens
- User Management — Create, list, and delete users with bcrypt-hashed passwords
- Endpoint Scopes — Restrict which tokens can call which endpoints via
/auth/scopes - MCP Integration — AI agent playground and MCP tools, with scope enforcement
- Logs & Status — View service logs and status (PID, uptime) from the dashboard
Typical Production Setup
After deploying services with micro deploy:
# On your server, start the dashboard
micro server
Services managed by systemd are discovered via the registry and appear in the dashboard automatically. The server provides the authenticated API and web UI for interacting with them.
When to use it
- You have services running in production (via systemd or otherwise) and want a web UI
- You need authenticated API access with JWT tokens
- You want user management and token revocation
- You're running a shared environment where multiple people interact with services
For CLI usage details, see the CLI documentation on GitHub.