DigitalOcean App Platform: PaaS Guide

What is DigitalOcean App Platform?

App Platform is DigitalOcean's fully managed Platform-as-a-Service (PaaS) that lets you build, deploy, and scale applications without managing servers, load balancers, or networking infrastructure. It supports multiple languages and frameworks out of the box, automatically detects your project type, builds your code from source, handles SSL certificates, and provides built-in horizontal scaling. Think of it as DigitalOcean's answer to Heroku, Render, or Railway, but deeply integrated with the DigitalOcean ecosystem.

App Platform supports several component types: Services (long-running web servers), Static Sites (HTML/CSS/JS served from CDN), Workers (background processing without HTTP endpoints), Jobs (one-off or scheduled tasks), and Functions(serverless handlers). You can combine these components in a single app with shared environment variables, databases, and domains.

Getting Started

Connecting Your Repository

App Platform deploys from GitHub, GitLab, or DigitalOcean Container Registry. The most common setup is connecting a GitHub repository with automatic deployments on push. When you connect a repository, App Platform automatically detects the language and framework, selects the appropriate buildpack, and generates a build and run configuration.

Supported Languages and Frameworks

App Platform has built-in buildpacks for Node.js, Python, Go, Ruby, PHP, Java, Scala, Clojure, Rust, and static sites. It also supports Dockerfile-based deployments for any language or runtime not covered by buildpacks. For each supported language, App Platform automatically detects the package manager, dependency file, build command, and start command.

App Spec Configuration

Every App Platform application is defined by an App Spec, a YAML document that describes all components, environment variables, databases, domains, and scaling settings. You can define the spec in a .do/app.yaml file in your repository or configure it through the control panel.

name: my-fullstack-app
region: nyc

services:
  - name: api
    github:
      repo: myorg/api-service
      branch: main
      deploy_on_push: true
    build_command: npm run build
    run_command: npm start
    environment_slug: node-js
    instance_count: 2
    instance_size_slug: professional-xs
    http_port: 3000
    routes:
      - path: /api
    health_check:
      http_path: /api/health
      initial_delay_seconds: 10
      period_seconds: 15
      timeout_seconds: 5
      success_threshold: 1
      failure_threshold: 3
    envs:
      - key: DATABASE_URL
        scope: RUN_TIME
        type: SECRET
        value: EV[1:encrypted-value]
      - key: NODE_ENV
        scope: RUN_AND_BUILD_TIME
        value: production
    autoscaling:
      min_instance_count: 2
      max_instance_count: 5
      metrics:
        cpu:
          percent: 70

  - name: worker
    github:
      repo: myorg/api-service
      branch: main
      deploy_on_push: true
    build_command: npm run build
    run_command: npm run worker
    environment_slug: node-js
    instance_count: 1
    instance_size_slug: professional-xs

static_sites:
  - name: frontend
    github:
      repo: myorg/frontend
      branch: main
      deploy_on_push: true
    build_command: npm run build
    output_dir: dist
    environment_slug: node-js
    routes:
      - path: /
    envs:
      - key: VITE_API_URL
        scope: BUILD_TIME
        value: /api

databases:
  - name: app-db
    engine: PG
    production: true
    cluster_name: prod-pg-cluster

domains:
  - domain: app.example.com
    type: PRIMARY

Component Types

Services

Services are long-running processes that handle HTTP traffic. They are the primary component type for web servers, APIs, and any application that responds to HTTP requests. Services can be scaled horizontally with multiple instances and include built-in health checks to ensure traffic is only routed to healthy instances. App Platform automatically provisions a managed SSL certificate for your custom domain and handles TLS termination.

Static Sites

Static Sites serve pre-built HTML, CSS, JavaScript, and assets from DigitalOcean's global CDN. They are ideal for React, Vue, Angular, Next.js (static export), and other single-page applications. Static sites build from source, deploy the output directory to CDN edge nodes worldwide, and cost nothing on the free tier (3 static sites included). Build environment variables are injected at build time using theBUILD_TIME scope.

Workers

Workers are long-running processes without HTTP endpoints. They are used for background processing, queue consumers, scheduled data processing, and any task that runs continuously but does not serve web traffic. Workers share the same codebase and environment as services but do not receive HTTP traffic through the App Platform router.

Jobs

Jobs are short-lived processes that run to completion. They can be triggered manually, on a schedule (cron), or before/after deployments. Common use cases include database migrations (pre-deploy jobs), data exports, report generation, and cleanup tasks.

jobs:
  - name: db-migrate
    github:
      repo: myorg/api-service
      branch: main
    build_command: npm run build
    run_command: npm run migrate
    environment_slug: node-js
    instance_size_slug: basic-xxs
    kind: PRE_DEPLOY
    envs:
      - key: DATABASE_URL
        scope: RUN_TIME
        type: SECRET
        value: EV[1:encrypted-value]

  - name: daily-report
    github:
      repo: myorg/api-service
      branch: main
    build_command: npm run build
    run_command: npm run generate-report
    environment_slug: node-js
    instance_size_slug: basic-xxs
    kind: CRON
    cron: "0 6 * * *"

Instance Sizes and Pricing

App Platform offers two tiers of instance sizes: Basic (shared CPU, starting at $5/month) and Professional (dedicated CPU, starting at $12/month). The free tier includes 3 static sites and 1 Basic application with 1 instance.

Basic Tier (shared CPU):
  basic-xxs  - 1 vCPU, 512 MB  - $5/mo
  basic-xs   - 1 vCPU, 1 GB    - $10/mo
  basic-s    - 1 vCPU, 2 GB    - $20/mo
  basic-m    - 2 vCPU, 4 GB    - $40/mo

Professional Tier (dedicated CPU):
  professional-xs  - 1 vCPU, 1 GB   - $12/mo
  professional-s   - 1 vCPU, 2 GB   - $25/mo
  professional-m   - 2 vCPU, 4 GB   - $50/mo
  professional-l   - 4 vCPU, 8 GB   - $100/mo
  professional-xl  - 8 vCPU, 16 GB  - $200/mo

Auto-Scaling

Professional tier services support horizontal auto-scaling based on CPU utilization. When average CPU usage across instances exceeds the configured threshold (e.g., 70%), App Platform adds instances up to the maximum count. When usage drops, instances are removed down to the minimum count. Scaling events typically take 30-60 seconds.

services:
  - name: api
    instance_count: 2
    instance_size_slug: professional-xs
    autoscaling:
      min_instance_count: 2
      max_instance_count: 10
      metrics:
        cpu:
          percent: 70

Database Integration

App Platform can attach managed databases directly to your application. You can use a dev database (single-node, included free with App Platform) for development, or connect to an existing production database clusterfor production workloads. Database connection strings are automatically injected as environment variables.

Custom Domains and SSL

App Platform manages SSL certificates automatically using Let's Encrypt. Add your custom domain in the App Spec, point your DNS to the App Platform CNAME target, and SSL is provisioned within minutes. Both apex domains (example.com via A record) and subdomains (app.example.com via CNAME) are supported.

Deployment Strategies

App Platform uses a zero-downtime rolling deployment strategy by default. New instances are created with the updated code, health checks pass, and then old instances are drained and removed. If the new deployment fails health checks, the rollback is automatic and the previous version continues serving traffic.

# Deploy from CLI
doctl apps create --spec .do/app.yaml

# List apps
doctl apps list

# Get deployment logs
doctl apps logs <app-id> --type=deploy

# Get runtime logs
doctl apps logs <app-id> --type=run

# Rollback to previous deployment
doctl apps create-deployment <app-id> --force-rebuild

When to Use App Platform vs. DOKS

• Use App Platform when you want zero-ops deployment from Git, simple scaling, and do not need custom networking, persistent storage, or complex orchestration.
• Use DOKS when you need full Kubernetes flexibility, custom networking (Network Policies, service mesh), persistent volumes, stateful workloads, or multi-container pods.
• Use both when your frontend and simple API are well-served by App Platform, but your data processing pipeline needs Kubernetes. They can communicate via private networking in the same VPC.