# What is Dewy and What Problem Does It Solve? A Declarative Deployment Tool for Non-Kubernetes Environments

> Discover Dewy, a declarative deployment tool for bare-metal and VMs. Solve your CI/CD challenges without Kubernetes by automatically deploying artifacts from various registries.

- Repository: [Tomohisa Oda/dewy](https://github.com/linyows/dewy)
- Tags: getting-started
- Published: 2026-03-06

---

**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`](https://github.com/linyows/dewy/blob/main/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`](https://github.com/linyows/dewy/blob/main/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`](https://github.com/linyows/dewy/blob/main/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`](https://github.com/linyows/dewy/blob/main/artifact/artifact.go) handles downloading and caching. Artifacts are stored in a local filesystem cache managed by [`kvs/file.go`](https://github.com/linyows/dewy/blob/main/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`](https://github.com/linyows/dewy/blob/main/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.

```bash
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.

```bash
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.

```bash
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`](https://github.com/linyows/dewy/blob/main/dewy.go), which provides the `Dewy` struct and configuration options.

```go
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`](https://github.com/linyows/dewy/blob/main/registry/registry.go)), artifacts ([`artifact/artifact.go`](https://github.com/linyows/dewy/blob/main/artifact/artifact.go)), and notifiers ([`notifier/notifier.go`](https://github.com/linyows/dewy/blob/main/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`](https://github.com/linyows/dewy/blob/main/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`](https://github.com/linyows/dewy/blob/main/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`](https://github.com/linyows/dewy/blob/main/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`](https://github.com/linyows/dewy/blob/main/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.