Kaupang: deploy the same config to Docker Compose, Swarm, or Kubernetes

#node #kubernetes #devops #docker

I just released kaupang — Old Norse for a Viking trading hub, where goods from every craft were gathered, packed, and shipped. It's an imperative, push-based deploy
CLI: you point it at a config, it makes a target match it, records exactly what it did, and lets you replay or roll back. The same command runs on your laptop and in CI.

The itch

Every project ended up with its own deploy glue — a compose file here, a kubectl apply there, a hand-rolled promotion script — and none of it behaved the same locally as it did in the pipeline. I wanted one definition that could target whatever backend a given environment used, run identically everywhere, and make "what I tested is what I ship" the default instead of a hope.

What it looks like

// kaupang.config.ts
import { defineConfig } from "@kaupang/core";

export default defineConfig({
  environments: "./environments",
  project: "shop",
  dockerRepository: "ghcr.io/acme",
});

// environments/api.ts
import { defineEnvironment } from "@kaupang/core";

export default defineEnvironment({
  services: {
    web: { image: "shop-api", ports: ["8080:3000"] },
  },
});

kaupang up api --target staging   # resolve images → pin digests → deploy → record
kaupang up api --dry-run          # show the dependency graph + commands, run nothing
kaupang rollback api --target prod

What makes it different

Multi-backend from one config — Compose, Swarm, or Kubernetes, same env definition.
Immutable & auditable — every deploy resolves tags to a digest, pins it, and records the full artifact in a ledger. Staging validates a digest; prod redeploys that exact digest. rollback replays a known-good snapshot.
Airgap-friendly — pack a "solution" with pinned digests into a portable OCI bundle, ship it over oras, and deploy it with no registry access on the far side.
Composes with CI, doesn't compete — it's a push tool, not a reconciler. Your pipeline keeps triggers, approvals, and secrets; kaupang owns the deploy recipe.

Status

v0.1.0, MIT. Every deploy path is exercised end-to-end against real Docker and a kind cluster in CI. The Kubernetes backend is intentionally minimal (Namespace + Deployment + Service) — it's for straightforward services, not a Helm replacement.