Build a CI/CD Pipeline with DigitalOcean App Platform and GitHub (2026)

DigitalOcean App Platform can deploy directly from GitHub, but its magic is in abstracting away the underlying infrastructure so you can focus on code, not servers.

Let’s say you’ve got a web app in a GitHub repository. You want to get it running on DigitalOcean, automatically build and deploy on every git push.

First, head to your DigitalOcean dashboard and click "Create" -> "Apps". You’ll be prompted to connect your GitHub account. Grant it access to the repositories you want to use.

Once connected, select the repository and branch you want to deploy. App Platform will then try to auto-detect your app’s build and run commands. For a Node.js app, it might suggest npm install for build and npm start for run. For Python, pip install -r requirements.txt and gunicorn app:app. You can override these if needed.

Here’s a sample digitalocean.yaml you’d place in your repository’s root if auto-detection fails or you want explicit control:

# digitalocean.yaml
name: my-awesome-app
services:
  - name: web
    git:
      branch: main
      repo: https://github.com/yourusername/my-awesome-app.git
    build_command: npm install
    run_command: npm start
    health_check:
      path: /health
      port: 3000
    http_port: 3000
    instance_size: basic-xxs
    autoscale: true
    autoscale_metrics:
      - cpu
    instance_count: 1

This config tells App Platform to:

• Name the app my-awesome-app.
• Watch the main branch of yourusername/my-awesome-app.git.
• Run npm install to build dependencies.
• Execute npm start to launch the application.
• Check /health on port 3000 to ensure it’s running.
• Use a basic-xxs instance size.
• Enable autoscale based on CPU usage, starting with 1 instance.

After selecting your repo and branch, App Platform shows you a summary of its detected settings. You can edit these directly in the UI or choose to generate a digitalocean.yaml file in your repository. It’s generally better to commit this file to your repo for version control.

App Platform creates a "build" environment. It pulls your code, installs dependencies using your build_command, and then packages it. For web apps, it then starts your run_command and exposes it on a public port.

For databases or background workers, you can add other services. For instance, to add a Redis cache:

# digitalocean.yaml (snippet for adding Redis)
services:
  - name: web
    # ... other web service config
  - name: redis
    image: redis:6.2
    internal_port: 6379
    mount_path: /var/lib/redis

This defines a redis service using the redis:6.2 Docker image. It’s only accessible internally, so your web service can connect to redis://localhost:6379 (or a dynamically assigned internal hostname). The mount_path ensures data persistence.

When you push a change to your connected GitHub branch, App Platform automatically triggers a new build and deploy. You can monitor the progress in the DigitalOcean dashboard, seeing logs from the build and deployment phases.

Environment variables are crucial for configuration. You set these in the "Edit" -> "Environment Variables" section of your App Platform app. These are injected into your running containers. For example, to set a database URL:

• Key: DATABASE_URL
• Value: postgresql://user:password@db.example.com:5432/mydb (or redis://redis-service:6379 if it’s an internal App Platform service)
• Environment: Production (or Staging, Development)

App Platform manages the underlying Droplets, Kubernetes clusters, or serverless functions for you. It provides a load balancer, SSL certificates (auto-renewed), and scaling capabilities out of the box. You don’t SSH into anything.

The most surprising thing about DigitalOcean App Platform is how opinionated it is about its default choices, which can be a double-edged sword. While it excels at making common web application deployments trivial, deviating from those common patterns can sometimes require a deeper understanding of its underlying abstractions and potentially fighting against its defaults, which are often geared towards PaaS-like simplicity rather than full infrastructure control.

When you first set up your app, you’ll notice a DIGITALOCEAN_APP_ID and DIGITALOCEAN_APP_URL environment variable appear automatically. These are useful for your application to know its own identity within the App Platform, allowing for self-referential logging or internal service discovery if needed.

After your first successful deployment, you’ll likely want to configure custom domains and set up alerts for when your app becomes unhealthy.