Skip to main content

Deployment Model

Radish supports more than one deployment and operating model.

Local / Repository-Centric Use​

At the simplest level, Radish CLI is used directly inside an application repository.

In this model:

  • blueprints live in the repo
  • generated architecture lives in the repo
  • developers work locally
  • standard Git workflows apply

Hub-Orchestrated Use​

Radish Hub can manage applications and blueprints at a higher level.

In this model, Hub provides:

  • blueprint organization
  • app-level orchestration
  • generation history
  • deployment coordination
  • telemetry collection and historical dashboards

Cloud-Managed Use​

Radish Cloud adds a hosted management layer on top of hubs and environments.

A team may use:

  • a single hosted hub
  • multiple hubs
  • self-hosted hubs registered to cloud management
  • separate hubs for staging and production
  • one hub with multiple app environments

Generated Deployment Artifacts​

Every app created with radish create app includes production-ready deployment files:

Dockerfile​

  • Base image: Debian slim (not Alpine) for native module compatibility
  • Multi-stage build: Dependencies installed first, then source copied (layer caching)
  • Healthcheck: node -e "fetch('http://localhost:3000/api/health')..." (always available, no wget needed)
  • Non-root user: Runs as node user

docker-compose.yml​

  • Uses expose (not ports) — Traefik or a reverse proxy handles external routing
  • pull_policy: always — ensures latest image on redeploy
  • Registry image reference with IMAGE_TAG variable
  • Numeric BODY_SIZE_LIMIT (bytes, not string)
  • Node healthcheck matching the Dockerfile pattern

.gitlab-ci.yml​

  • Uses built-in CI_REGISTRY, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD variables (zero config)
  • Kaniko build on tag push (e.g., v0.1.0)
  • Triggers deployment via POST /api/v1/deploy to Coolify
  • Response capture for CI logs

Deployment Pipeline​

git tag v0.1.0 → git push --tags
  → GitLab CI: Kaniko builds Docker image
  → Pushes to registry (registry.mini1.abeedoo.com)
  → POST /api/v1/deploy triggers Coolify
  → Coolify pulls image, starts container
  → Traefik routes traffic to new container
  → /api/health confirms readiness

Provisioning with radish deploy init​

The deploy init command provisions apps on Coolify:

# One-time: configure your Coolify instance
cfy setup

# Per-project: provision the app
radish deploy init

This creates a Docker image app on Coolify, sets environment variables, configures health checks, and saves the target config to .radish.deploy.json.

Prerequisites: cfy CLI (npm install -g @abeedoo/cfy)

See the CLI Reference for full options.

Portability​

A core requirement of the platform is portability.

Teams should be able to:

  • take the repository
  • keep the blueprints
  • keep the generated architecture
  • continue using Radish CLI
  • or take full ownership without the rest of the platform