Skip to Content
DocsIntroduction

Introduction

Jiji deploys containerized applications across multiple servers with health-gated rolling updates, private networking, and simple YAML configuration.

Why Jiji?

  • Fail-safe rolling deployments - a failed candidate is removed before it receives traffic, while the healthy version keeps serving
  • Multi-server support - deploy across servers with parallel SSH execution
  • Container engine agnostic - works with Docker or Podman
  • Private networking - a per-project WireGuard mesh with automatic .jiji DNS service discovery
  • Scheduled jobs - run service commands on cron schedules in isolated one-off containers
  • Simple configuration - everything lives in one YAML file

How It’s Built

The core deployment system uses the jiji CLI locally and a per-project jiji-agent on each server. The CLI reads deploy.yml, works out network topology and container placement, and drives selected servers over SSH. The agent, installed by jiji server setup, continuously owns membership, DNS, the service catalog, desired placement, and address leases on its host. Public ingress is handled by the separately packaged jiji-proxy container.

Private networking is a WireGuard mesh between your servers, with each project’s agents serving replicated .jiji DNS records. Deployments receive fresh leased addresses, and proxy routes follow the healthy Active records in the replicated catalog. See Architecture for the full picture.

Quick Example

# .jiji/deploy.yml project: myapp builder: engine: docker servers: web1: host: server1.example.com web2: host: server2.example.com services: api: build: context: . dockerfile: Dockerfile servers: - web1 - web2 proxy: port: 3000 hosts: - api.example.com ssl: true healthcheck: path: /health crons: remove-expired: schedule: "0 3 * * *" command: ["npm", "run", "remove-expired"]
# Set up the servers (container engine + private network) jiji server setup
# Build and deploy with a health-gated rolling update jiji deploy --build

Next Steps

Last updated on