What is Dewy and What Problem Does It Solve? A Declarative Deployment Tool for Non-Kubernetes Environments
Dewy is a Go-based deployment agent that enables declarative, pull-based continuous delivery for bare-metal and VM environments without requiring Kubernetes, automatically fetching and deploying artifacts from registries like GitHub Releases, S3, or OCI.
What is Dewy and what problem does it solve? Dewy addresses the critical gap between modern continuous delivery pipelines and traditional infrastructure that lacks container orchestration. As a single static binary written in Go, it provides Kubernetes-like deployment automation for servers and virtual machines by continuously polling configured registries, detecting new semantic versions, and executing zero-downtime updates with built-in health checks and notifications.
The Deployment Gap: Why Dewy Exists
Most continuous delivery solutions assume either a Kubernetes cluster or complex push-based scripts that require external orchestration. Dewy solves this by implementing a pull-based deployment model directly on the target host. It continuously polls a configured registry—such as GitHub Releases, Amazon S3, Google Cloud Storage, OCI registries, or GRPC endpoints—to determine the latest semantic version. When a new version is detected, Dewy automatically fetches the corresponding artifact, performs health checks, and executes the deployment with zero downtime.
This approach eliminates the need for external deployment scripts or SSH-based push mechanisms, making it ideal for edge deployments, standalone servers, and VM-based infrastructure where installing Kubernetes would be impractical.
Core Architecture and Components
Dewy’s architecture follows a modular design that separates concerns between registry detection, artifact handling, and deployment execution. The implementation in dewy.go contains the core scheduler and polling logic, while specialized interfaces handle specific protocols.
Registry Abstraction and Version Resolution
The Registry interface in registry/registry.go defines how Dewy interacts with different artifact sources. It supports multiple URL schemes including ghr:// for GitHub Releases, s3://, gs://, img:// for OCI images, and grpc://.
The GitHub Releases implementation in registry/ghr.go demonstrates the version resolution logic. It resolves the latest release using semantic versioning, supports artifact pattern matching for specific file names, and handles slot extraction for canary deployments. The Resolve() method returns the latest version and download URL, which the scheduler uses to trigger deployments.
Artifact Handling and Caching
Once a version is identified, the Artifact interface in artifact/artifact.go handles downloading and caching. Artifacts are stored in a local filesystem cache managed by kvs/file.go, which maintains the current symlink pointing to the active version. This enables atomic rollbacks and ensures zero-downtime updates by switching symlinks only after health checks pass.
Deployment Modes in Practice
Dewy supports three primary deployment modes, each optimized for different application types. These are invoked via subcommands in cmd/dewy/main.go.
Server Mode: Binary Deployment
For Go or compiled applications, Dewy acts as a process supervisor. It downloads the latest binary artifact, extracts it, and manages the process lifecycle.
dewy server \
--registry ghr://linyows/myapp \
--notifier slack://general?title=myapp \
-p 8000 -l info \
-- /opt/myapp/current/myapp
The server command creates a supervisor that monitors the registry, downloads the newest binary artifact, extracts it, and restarts the managed process when the version changes. The -p 8000 flag configures the health check port, ensuring zero-downtime restarts only after the new process passes health checks.
Assets Mode: Static File Deployment
For frontend applications or static sites, Dewy synchronizes files to a web server directory.
dewy assets \
--registry ghr://linyows/frontend \
-d /var/www/html \
-l info
This deploys static files (HTML/CSS/JS) to a target directory, keeping the latest release symlinked as current. The atomic symlink switch ensures web servers never serve partial or corrupted files during an update.
Container Mode: Zero-Downtime Docker Deployment
For containerized applications without Kubernetes, Dewy implements blue/green deployment using a built-in TCP proxy.
dewy container \
--registry img://ghcr.io/linyows/myapp \
--port 8080 --health-path /health --replicas 3 \
-- -e DATABASE_URL=postgres://db:5432/mydb -v /data:/app/data
This pulls the OCI image from the specified registry, starts the configured number of replicas behind a TCP proxy, performs health checks, and swaps traffic atomically. The --replicas flag enables horizontal scaling while maintaining zero-downtime guarantees.
Programmatic Usage with the Go API
Beyond CLI usage, Dewy exposes a Go API for integration into custom tooling. The main entry point is in dewy.go, which provides the Dewy struct and configuration options.
import (
"github.com/linyows/dewy"
"github.com/linyows/dewy/logging"
)
func main() {
log := logging.New(logging.INFO)
cfg := dewy.Config{
Registry: "ghr://linyows/myapp",
Command: dewy.SERVER,
Starter: dewy.StarterConfig{Command: "/opt/myapp/current/myapp"},
}
d, _ := dewy.New(cfg, log)
d.Start(10) // poll every 10 seconds
}
This creates a Dewy instance, configures it with a registry and server command, then starts the scheduler polling every 10 seconds. The API supports all deployment modes and notification configurations available in the CLI.
Summary
- Dewy is a single-binary Go application that brings declarative, pull-based continuous delivery to bare-metal and VM environments without Kubernetes.
- It solves the deployment gap by continuously polling registries (GitHub Releases, S3, OCI, etc.) for new semantic versions and automatically deploying artifacts with zero downtime.
- The architecture uses modular interfaces for registries (
registry/registry.go), artifacts (artifact/artifact.go), and notifiers (notifier/notifier.go), enabling extensibility. - Three deployment modes support diverse workloads: server for binaries, assets for static files, and container for Docker images with blue/green routing.
- Both CLI and Go API (
dewy.go) provide flexible integration options for infrastructure automation.
Frequently Asked Questions
What is Dewy and what problem does it solve for DevOps teams?
Dewy is a pull-based deployment agent written in Go that eliminates the need for complex push scripts or Kubernetes clusters when deploying to bare-metal servers or VMs. It solves the operational burden of manually coordinating deployments across non-containerized infrastructure by automatically detecting new releases in registries like GitHub Releases or S3 and performing zero-downtime updates with built-in health checking.
How does Dewy differ from traditional CI/CD deployment scripts?
Unlike traditional push-based scripts that require external orchestration to SSH into servers and execute commands, Dewy uses a pull-based model where the agent running on the target host polls the registry directly. This approach, implemented in dewy.go, removes the need for persistent inbound access or complex orchestration layers while providing atomic deployments through symlink switching and automatic rollback capabilities.
What registry types does Dewy support for artifact resolution?
Dewy supports multiple registry backends through its abstract Registry interface defined in registry/registry.go, including GitHub Releases (ghr://), Amazon S3 (s3://), Google Cloud Storage (gs://), OCI container registries (img://), and GRPC endpoints. The GitHub Releases implementation in registry/ghr.go specifically handles semantic version resolution, artifact pattern matching, and slot-based canary deployments.
Can Dewy be integrated into existing Go applications or automation tools?
Yes, Dewy exposes a comprehensive Go API that allows programmatic control beyond the CLI interface. Developers can import github.com/linyows/dewy and use the dewy.New() function to create configured instances, set custom logging via logging.New(), and control polling intervals through the Start() method. This enables integration into existing infrastructure automation, custom deployment controllers, or embedded edge computing scenarios.
Have a question about this repo?
These articles cover the highlights, but your codebase questions are specific. Give your agent direct access to the source. Share this with your agent to get started:
curl -s "https://instagit.com/install.md" Maintain an open-source project? Get it listed too →