* feat(cli): add color output to micro chat and micro api
micro chat:
- Startup banner matching micro run style: bold header, cyan
provider/model, green dots for each discovered tool endpoint
- Cyan bold prompt (> ) instead of plain
- Yellow arrow (→) with dimmed tool name for tool calls
- Red "error:" prefix for errors
- Dimmed "(history cleared)" for reset
micro api:
- Startup banner matching micro run style: bold header, cyan
address, colored HTTP methods (green GET, yellow POST)
Brings the CLI UX closer to what the generated terminal
screenshot depicts — color-coded, professional, readable.
* feat(cli): adopt consistent color output across all commands
Apply the same banner/output style across the remaining commands:
micro new: bold header, cyan service name, green ✓, cyan URLs
micro build: green ✓ checkmarks, cyan file paths
micro deploy: bold header, cyan target
micro mcp: bold header, green dots per tool, dimmed count
micro flow: bold header, cyan flow/topic/provider
All commands now follow the micro run/chat/api pattern:
bold header, cyan values, green status indicators, dimmed hints.
* docs: add "Tools as Services" blog post
Write blog/12 — connects the AI story back to Go Micro's original
design: services were always self-describing, named, and uniformly
callable. The path from API gateway to MCP to LLM tools is the
same pattern — read the registry, present services in a format
the consumer understands, route calls back.
Covers the access layer pattern (HTTP, web, CLI, MCP, chat),
why doc comments became functional in the AI era, and how the
framework primitives (registry, broker, store) could all become
tools using the same mechanism.
Add to blog index, link forward from blog/11.
---------
Co-authored-by: Claude <noreply@anthropic.com>
* Add systemd-based deployment support
- micro init --server: Initialize server to receive deployments
- Creates /opt/micro/{bin,data,config} directories
- Generates systemd template unit (micro@.service)
- Creates 'micro' system user
- micro deploy: Deploy services via SSH + systemd
- Builds linux/amd64 binaries automatically
- Copies via rsync/scp to server
- Manages services via systemctl
- Helpful error messages for common issues
- micro status --remote: Check remote service status
- micro logs --remote: Stream remote logs via journalctl
- micro stop --remote: Stop services on remote server
- Config: Added 'deploy' blocks to micro.mu for named targets
The deployment model:
- systemd is the process supervisor (battle-tested)
- SSH is the transport (standard, secure)
- No custom daemons or platforms needed
Co-authored-by: Shelley <shelley@exe.dev>
* Add deployment documentation
- docs/deployment.md: Comprehensive guide for server deployment
- README.md: Updated deployment section with full workflow
Co-authored-by: Shelley <shelley@exe.dev>
* Add deployment section to CLI documentation
Co-authored-by: Shelley <shelley@exe.dev>
* Fix systemd template escaping and rsync permission warnings
- Fix %i escaping in systemd template (was being interpreted by fmt.Sprintf)
- Handle rsync exit code 23/24 gracefully (metadata permission warnings)
- Add --omit-dir-times to rsync to avoid directory timestamp errors
Co-authored-by: Shelley <shelley@exe.dev>
* Add install script for micro CLI
Co-authored-by: Shelley <shelley@exe.dev>
* Fix non-constant format string in deploy error
Co-authored-by: Shelley <shelley@exe.dev>
---------
Co-authored-by: Shelley <shelley@exe.dev>
micro build:
- Default: builds Go binaries to ./bin/
- Cross-compile with --os and --arch
- Docker is optional via --docker flag
micro deploy:
- Requires --ssh user@host
- Copies pre-built binaries (if ./bin/ exists)
- Or syncs source and builds on remote
- No Docker dependency
Go binaries are self-contained. No runtime needed.
Co-authored-by: Shelley <shelley@exe.dev>
Asim Aslam