What is the relationship between an App Platform app and a GitHub repo?

Each app can connect to a GitHub or GitLab repo and auto-deploy on pushes to a configured branch. You can connect multiple components in one app to different repos, or use container images instead of source code. The connection is one-way: DO pulls from the repo when triggered, not the reverse.

How do environment variables and secrets work?

Each component has its own environment variable scope, and you can mark a variable as a secret to encrypt it at rest. Variables can also be defined at the app level and inherited by all components. Secrets are not visible in the dashboard after creation — you can only overwrite them, not read them — which is correct behavior for production credentials.

DO App Platform Config Builder

ComputeDigitalOcean

Build DigitalOcean App Platform spec configurations with services, static sites, and databases.

Last verified: May 2026

DigitalOcean App Platform Configuration

Build DigitalOcean App Platform spec configurations with services, static sites, workers, jobs, databases, and auto-scaling.

Required Fields

spec.namespec.regionspec.services

{
  "spec": {
    "name": "my-web-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
        },
        "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
            }
          }
        }
      }
    ],
    "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": "/"
          }
        ]
      }
    ],
    "databases": [
      {
        "name": "app-db",
        "engine": "PG",
        "production": true,
        "cluster_name": "prod-pg-cluster"
      }
    ],
    "domains": [
      {
        "domain": "app.example.com",
        "type": "PRIMARY"
      }
    ]
  }
}

Generated Output

Output will appear here...

About This Tool

DigitalOcean App Platform is a PaaS layer above DOKS — push code or a container image, get a managed web service with autoscaling, environment-specific configuration, and built-in load balancing. The DO App Platform Config Builder produces the YAML spec that defines an app: web services, workers, static sites, databases, and the inter-service routing between them. It validates instance sizes, port mappings, and database tier choices against current App Platform constraints.

Real-World Scenario

A small team has been managing a Rails app and Sidekiq worker on a pair of Droplets with systemd and capistrano. Every deploy is brittle. You generate an App Platform spec with the builder — web service for Rails, worker for Sidekiq, managed Postgres as the database — and migrate. The deploy story collapses from a 30-step capistrano runbook to `git push`. The team gets back about a day per month of operational toil.

When to Use This Tool

•Defining a new App Platform app spec for a web service and a background worker that share a managed Postgres database.
•Adding a static site (frontend build artifact) to an existing app spec without rebuilding the API services.
•Migrating an existing web service from Droplets to App Platform by translating systemd unit configuration into the equivalent spec.
•Documenting an app's structure in a versioned spec file so deployment configuration lives alongside code.

Pro Tips

TIP

Pin the build command and runtime explicitly. App Platform's autodetection is convenient for prototypes but can pick a different Node or Python version after a routine commit if your package manifest changes. Pinning avoids the surprise deploy.

TIP

Use the `routes` section to put a static frontend and an API backend behind a single hostname. Without it, you end up with separate domains for each component and CORS headaches that App Platform's same-origin routing would have prevented.

How It Works Under the Hood

The builder collects the app name, region, and a list of components (services, workers, static sites, jobs, databases). For each component it validates the source (git or registry), build/run commands, environment variables, port mapping, and instance size against the App Platform spec. The output is a YAML spec that matches the `doctl apps create --spec` schema and can be checked into the repo.

Frequently Asked Questions

What is the relationship between an App Platform app and a GitHub repo?: Each app can connect to a GitHub or GitLab repo and auto-deploy on pushes to a configured branch. You can connect multiple components in one app to different repos, or use container images instead of source code. The connection is one-way: DO pulls from the repo when triggered, not the reverse.
How do environment variables and secrets work?: Each component has its own environment variable scope, and you can mark a variable as a secret to encrypt it at rest. Variables can also be defined at the app level and inherited by all components. Secrets are not visible in the dashboard after creation — you can only overwrite them, not read them — which is correct behavior for production credentials.

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.