Asim Aslam
550033dcce
* perf: convert generated PNGs to optimized JPEGs (12MB -> 1.5MB) The landing and docs loaded 18 AI-generated PNGs at 0.5-1MB each. They're 1200x800 RGB illustrations with no transparency, so they recompress ~8x as progressive JPEG (quality 82) with no visible loss. Convert all, update every reference (.png -> .jpg), and drop the originals (including the unused hero.png). Generated images: 12.3MB -> 1.5MB. * fix(registry/etcd): re-register when a lease silently expires (#2956) The keepalive rework (long-lived KeepAlive instead of KeepAliveOnce) moved lease renewal entirely onto the keepalive goroutine; the 30s periodic Register now skips on the 'unchanged' check. The goroutine only reacted to the keepalive channel closing, so a lease that expired server-side without a prompt channel close (e.g. a partition that outlasted the 90s TTL) left the node de-registered from etcd while the cache still believed it was registered — and nothing re-registered it. That is the hidden-failure mode reported in #2956. React to a non-positive TTL keepalive response the same as a channel close: drop the cached lease/hash so the next Register performs a full re-registration. Extract the loop into keepAliveLoop and unit-test the TTL-expired, channel-closed, and healthy paths (no etcd required). --------- Co-authored-by: Claude <noreply@anthropic.com>
3.0 KiB
layout, title, permalink, description
| layout | title | permalink | description |
|---|---|---|---|
| blog | Introducing micro deploy | /blog/1 | Deploy your Go Micro services to any Linux server with a single command |
Introducing micro deploy
January 27, 2026 • By the Go Micro Team
We're excited to announce micro deploy in Go Micro v5.13.0 — a simple way to deploy your services to any Linux server.
The Problem
Go Micro has always been great for building microservices:
micro new myservice
cd myservice
micro run
But getting those services to production? That was on you. You'd need to figure out Docker, Kubernetes, or write your own deployment scripts.
We tried to solve this with Micro v3 — a full platform-as-a-service. But it was too much. Too complex. Nobody wanted another platform to manage.
The Solution
The new approach is simple: systemd + SSH.
Every Linux server has systemd. It's battle-tested, it manages processes, it restarts them when they crash, it handles logging. Why reinvent it?
One-Time Server Setup
ssh user@server
curl -fsSL https://go-micro.dev/install.sh | sh
sudo micro init --server
This creates:
/opt/micro/bin/— where your binaries live/opt/micro/config/— environment files- A systemd template for managing services
Deploy
micro deploy user@server
That's it. The command:
- Builds your services for Linux
- Copies binaries via SSH
- Configures systemd services
- Verifies everything is running
Manage
micro status --remote user@server
micro logs --remote user@server
micro logs myservice --remote user@server -f
Named Deploy Targets
Add deploy targets to your micro.mu:
service users
path ./users
port 8081
service web
path ./web
port 8080
deploy prod
ssh deploy@prod.example.com
deploy staging
ssh deploy@staging.example.com
Then:
micro deploy prod
micro deploy staging
Philosophy
- systemd is the standard — don't fight it, use it
- SSH is the transport — no custom agents or protocols
- Errors guide you — every failure tells you how to fix it
- No platform — just your server, your services
What's Next?
This is just the beginning. We're thinking about:
- Secrets management — integrating with vault/sops
- Multi-server deploys — deploy to a fleet
- Metrics — Prometheus endpoints out of the box
- Rolling updates — zero-downtime deployments
Try It
go install go-micro.dev/v5/cmd/micro@v5.13.0
micro new myapp
cd myapp
micro run
# When you're ready to deploy:
micro deploy user@your-server
See the deployment guide for full documentation.
Go Micro is an open source framework for distributed systems development in Go. Star us on GitHub.