Blueprint Specification

Define your entire infrastructure as code with Deployado Blueprints. A single YAML file to deploy services, databases, and configure everything automatically.

Overview

A Deployado Blueprint is a YAML file (typically named deployado.yaml ) that defines your application's infrastructure. Place it in the root of your repository to enable one-click deployments.

File Location

The blueprint file must be named deployado.yaml and placed in the root directory of your repository.

Example Blueprint

Here's a complete example showing a typical web application with a database:

deployado.yaml 
# Project configuration
name: my-saas-app
repository: https://github.com/myuser/my-app
branch: main

# Databases
databases:
  - name: postgres-main
    version: "16"
    maxConnections: 100

# Reusable environment variable groups
envGroups:
  - name: common
    envVars:
      - key: NODE_ENV
        value: production

# Services/Applications
services:
  - name: api
    type: web
    runtime: repo
    port: 3000
    healthCheck:
      path: /health
    preDeployCommand: npm run migrate
    envGroups:
      - common
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: postgres-main
          property: connectionString
      - key: JWT_SECRET
        generateSecret: true
      - key: ADMIN_EMAIL
        prompt: true
        description: Admin email address

  - name: frontend
    type: web
    runtime: repo
    port: 80
    links:
      - service: api
        envVar: REACT_APP_API_URL

Root Fields

These fields are defined at the top level of your blueprint file.

Field Type Required Description
name string Required The name of your project. Used to create the project in Deployado.
repository string Optional GitHub repository URL. Can be github.com/user/repo or full HTTPS URL.
branch string Optional Git branch to deploy from. Default: main
project string Optional Existing project slug to import services into instead of creating a new project.
services array Required List of services/applications to deploy. Must have at least one.
databases array Optional List of PostgreSQL databases to provision.
envGroups array Optional Reusable groups of environment variables that can be shared across services.

Services

Services are the applications that make up your project. Each service is deployed as a container.

Service Fields

Field Type Default Description
name string Required Unique name for the service. Used in URLs and references.
type string web Service type. Currently supports web.
runtime string auto How to build/run the service:
  • auto - Auto-detect from repository
  • repo - Build from repository
  • docker - Build from Dockerfile
  • static - Static files (HTML/CSS/JS)
port integer 8080 Internal port your application listens on.
path string . Path within the repository where the service code is located.
server string auto Target server ID. If omitted, automatically selects an available server.
availabilityTier string basic Availability tier for the service.
preDeployCommand string - Command to run before each deployment (e.g., database migrations).
build object - Build configuration. See Build Fields below.
healthCheck object - Health check configuration. See Health Check Fields below.
envVars array - Environment variables for this service.
envGroups array - Names of environment groups to include.
links array - Links to other services. Creates environment variables with service URLs.

Build Fields

Field Type Description
dockerfile string Path to the Dockerfile (default: Dockerfile)
context string Docker build context path (default: .)
command string Custom build command to run

Health Check Fields

Field Type Default Description
path string /health HTTP path to check for health status
timeout integer 10 Timeout in seconds for health check requests

Links

Links allow services to discover each other. When you link service A to service B, service A gets an environment variable with service B's URL.

Field Type Description
service string Name of the service to link to (must exist in the blueprint)
envVar string Custom environment variable name. If omitted, generates SERVICE_NAME_URL

Databases

Define PostgreSQL databases that will be provisioned automatically. Services can reference these databases in their environment variables.

Field Type Default Description
name string Required Unique name for the database. Used to reference it from services.
version string 16 PostgreSQL version (e.g., "14", "15", "16")
server string auto Database server ID. If omitted, automatically selects an available server.
maxConnections integer 100 Maximum number of database connections
backupEnabled boolean true Whether automatic backups are enabled

Environment Variables

Environment variables can be defined in multiple ways: static values, generated secrets, references to databases, references to other services, or user prompts.

Field Type Description
key string Required - The environment variable name
value string Static value for the variable
generateSecret boolean If true, generates a random 32-character base64 URL-safe secret
prompt boolean If true, prompts the user to enter a value during deployment
description string Human-readable description (shown when prompting user)
fromDatabase object Reference to a database connection property. See Database References below.
fromService object Reference to another service's URL/host/port. See Service References below.

Examples

Static value 
envVars:
  - key: NODE_ENV
    value: production
Generated secret 
envVars:
  - key: JWT_SECRET
    generateSecret: true
User prompt 
envVars:
  - key: SENDGRID_API_KEY
    prompt: true
    description: Your SendGrid API key for email delivery

Environment Groups

Environment groups let you define reusable sets of environment variables that can be shared across multiple services.

Defining and using env groups 
# Define the group at root level
envGroups:
  - name: common-settings
    envVars:
      - key: LOG_LEVEL
        value: info
      - key: TZ
        value: UTC

# Reference it in services
services:
  - name: api
    envGroups:
      - common-settings  # Inherits LOG_LEVEL and TZ
    envVars:
      - key: API_PORT
        value: "3000"

  - name: worker
    envGroups:
      - common-settings  # Same env vars as api

Cross-References

Blueprints support referencing databases and services to automatically configure connection strings and URLs.

Database References

Use fromDatabase to get connection information from a database defined in the blueprint.

Field Description
name Name of the database (must match a database defined in databases)
property Which property to get (see table below)
driver Optional: Connection string driver format (auto by default)

Available database properties:

Property Example Value
connectionString postgres://user:pass@host:5432/dbname
url postgres://user:pass@host:5432/dbname
host db.internal.deployado.com
port 5432
user myapp_user
database / name myapp_production
Database reference example 
envVars:
  - key: DATABASE_URL
    fromDatabase:
      name: postgres-main
      property: connectionString

Service References

Use fromService to get URL/host information from another service.

Field Description
name Name of the service (must match a service defined in services)
property url, host, or port
Service reference example 
envVars:
  - key: API_ENDPOINT
    fromService:
      name: api
      property: url  # Results in: https://api.myproject.deployado.com

Validation Rules

Blueprints are validated before deployment. Here are the rules:

  • At least one service must be defined
  • Service names must be unique within the blueprint
  • Database names must be unique within the blueprint
  • All fromDatabase.name references must match an existing database
  • All fromService.name references must match an existing service
  • All links.service references must match an existing service
  • Environment variable keys must be valid (alphanumeric and underscores)