I’ve been working on an open source deployment tool called *Dewy*.
Dewy is a *single-binary deployment agent* that runs on each host and keeps your apps (binaries or containers) up to date, with *zero-downtime rollouts*, *pull-based updates*, and *no Kubernetes required*.
It’s for teams who:
- Run small to medium services on *VPS / bare metal* (a few to a few dozen servers)
- Can’t or don’t want to use *managed Kubernetes / Cloud Run / ECS* for cost, policy, or complexity reasons
- Already have CI, but the “deploy to production” step is still *SSH + shell scripts / rsync / scp*
- Worry about giving CI agents SSH access to production hosts
### How it works
- You publish *artifacts or images* from CI:
- e.g. GitHub Releases assets, S3 / GCS objects, or container images in a registry
- Dewy runs as a *daemon on each host*
- It periodically checks a *registry / storage / container registry* for the latest semantic version
- When a new version appears, Dewy:
- Downloads it
- Starts the new version
- Performs *zero-downtime switch-over*:
- For processes: graceful restart via signals
- For containers: Dewy acts as a reverse proxy and *drains old containers* (finish existing connections, route new traffic to the new version)
- Keeps multiple previous versions on disk so you can roll back safely
All of this is *pull-based*: production hosts reach out to fetch new releases. CI never SSHes into production, which reduces the attack surface.
### Why not Kubernetes?
Kubernetes (plus something like Argo CD) already gives you declarative, continuous deployments — but:
- Managed k8s can be *expensive* or *not allowed* in some orgs
- Self-hosting k8s can be *overkill* for small teams with a handful of nodes
- Many setups still have *long-lived VMs / bare metal* that are not going away soon
Dewy is *not* a replacement for Kubernetes. It doesn’t do scheduling or autoscaling. It focuses on a smaller problem:
> “Given some servers I already have, keep this service safely deployed and up to date, with minimal moving parts.”
### Safety & operations
- *Zero-downtime rollouts* via graceful restart / connection draining
- If the new version fails to start or health checks don’t pass, Dewy:
- Keeps the old version running
- Sends notifications (Slack / email)
- Avoids noisy repeated alerts
- Keeps several past releases locally for *quick manual rollback*
- Audit-friendly: you can see who released what and when through your Git tags / releases
### Cost & infra model
- Runs on *plain Linux servers* (VPS, small VMs, underpowered physical boxes)
- No control plane, no database required
- Just a *single static binary + a YAML config + systemd service*
If this sounds like something you’d use instead of hand-rolled SSH deploys or ad hoc scripts on non‑k8s infra, I’d love feedback:
linyows•2mo ago
I’ve been working on an open source deployment tool called *Dewy*.
Dewy is a *single-binary deployment agent* that runs on each host and keeps your apps (binaries or containers) up to date, with *zero-downtime rollouts*, *pull-based updates*, and *no Kubernetes required*.
It’s for teams who:
- Run small to medium services on *VPS / bare metal* (a few to a few dozen servers) - Can’t or don’t want to use *managed Kubernetes / Cloud Run / ECS* for cost, policy, or complexity reasons - Already have CI, but the “deploy to production” step is still *SSH + shell scripts / rsync / scp* - Worry about giving CI agents SSH access to production hosts
### How it works
- You publish *artifacts or images* from CI: - e.g. GitHub Releases assets, S3 / GCS objects, or container images in a registry - Dewy runs as a *daemon on each host* - It periodically checks a *registry / storage / container registry* for the latest semantic version - When a new version appears, Dewy: - Downloads it - Starts the new version - Performs *zero-downtime switch-over*: - For processes: graceful restart via signals - For containers: Dewy acts as a reverse proxy and *drains old containers* (finish existing connections, route new traffic to the new version) - Keeps multiple previous versions on disk so you can roll back safely
All of this is *pull-based*: production hosts reach out to fetch new releases. CI never SSHes into production, which reduces the attack surface.
### Why not Kubernetes?
Kubernetes (plus something like Argo CD) already gives you declarative, continuous deployments — but:
- Managed k8s can be *expensive* or *not allowed* in some orgs - Self-hosting k8s can be *overkill* for small teams with a handful of nodes - Many setups still have *long-lived VMs / bare metal* that are not going away soon
Dewy is *not* a replacement for Kubernetes. It doesn’t do scheduling or autoscaling. It focuses on a smaller problem:
> “Given some servers I already have, keep this service safely deployed and up to date, with minimal moving parts.”
### Safety & operations
- *Zero-downtime rollouts* via graceful restart / connection draining - If the new version fails to start or health checks don’t pass, Dewy: - Keeps the old version running - Sends notifications (Slack / email) - Avoids noisy repeated alerts - Keeps several past releases locally for *quick manual rollback* - Audit-friendly: you can see who released what and when through your Git tags / releases
### Cost & infra model
- Runs on *plain Linux servers* (VPS, small VMs, underpowered physical boxes) - No control plane, no database required - Just a *single static binary + a YAML config + systemd service*
If this sounds like something you’d use instead of hand-rolled SSH deploys or ad hoc scripts on non‑k8s infra, I’d love feedback:
- GitHub: https://github.com/linyows/dewy - Docs / landing page: https://dewy.linyo.ws