Skip to main content

Provider Adapters

Provider adapters describe how deployment intent is synchronized to each deployment target.

Supported Adapters​

Kubernetes​

  • Sync Pattern: Pull-based or push-based, depending on the chosen platform tooling
  • Typical Use: Multi-service or infrastructure-heavy workloads

Vercel​

  • Sync Pattern: Push-based via API
  • Trigger: CI applies deployment changes from the ops repo

Railway​

  • Sync Pattern: Push-based via API
  • Trigger: CI applies deployment changes from the ops repo

Droplet (SSH/Ansible)​

  • Sync Pattern: Push-based via SSH
  • Trigger: CI executes a deploy script or Ansible playbook

Adapter Contract​

Each adapter must provide:

1. Documentation​

adapter.md describing:

  • sync mechanics
  • required secrets and configuration
  • environment variables
  • deployment triggers

2. Workflow Integration​

  • example workflow snippet or composite action usage
  • configuration examples
  • error handling patterns

3. Acceptance Checklist​

  • deployment validation steps
  • rollback procedures
  • health check integration

Deployment Sync Patterns​

Pull-Based (Kubernetes)​

A pull-based deployment controller watches the ops repo and applies changes automatically:

Ops Repo Commit → Deployment Controller Detects Change → Applies to Cluster

Push-Based (Vercel/Railway)​

CI applies deployment changes from the ops repo via platform API:

Ops Repo Commit → CI Workflow Triggered → API Call to Platform → Deployment

SSH-Based (Droplet)​

CI executes a deployment script or Ansible playbook:

Ops Repo Commit → CI Workflow Triggered → SSH to Server → Execute Deploy Script

Choosing an Adapter​

Use Kubernetes when:​

  • need high scalability and orchestration
  • running a microservices architecture
  • require advanced deployment strategies
  • have a dedicated infrastructure team

Use Vercel when:​

  • deploying Next.js or frontend applications
  • need edge computing capabilities
  • want zero-configuration deployments
  • prioritize developer experience

Use Railway when:​

  • deploying full-stack applications
  • need database provisioning
  • want a simple deployment pipeline
  • are working with monolithic applications

Use Droplet when:​

  • need full server control
  • are running legacy applications
  • have custom infrastructure requirements
  • are cost-sensitive