openstead
Blueprints

Blueprint YAML reference

Supported manifest fields, service types, configuration mappings, and validation rules.

Suggest a change

Openstead manifests use UTF-8 YAML with a top-level services list. They support 1–30 service definitions and a maximum size of 64 KiB. YAML anchors and aliases are rejected; repeat each service's settings explicitly.

Minimal manifest

services:
  - name: example-api
    type: web
    plan: free
    runtime: node
    startCommand: npm start

Every service needs a unique name: up to 63 lowercase letters, digits, and hyphens, starting with a letter or digit. Always declare type and plan explicitly so a manifest communicates its intended resources.

Service types

typeService
webPublic web application or API.
staticBuilt static site.
privateInternal network service.
workerLong-running background process.
cronScheduled command.
postgresManaged PostgreSQL.
mysqlManaged MySQL.
redisRedis-compatible Key Value.

The parser accepts pserv, background_worker, and keyvalue as aliases for private, worker, and redis. Prefer the canonical names above.

Top-level service fields

YAML fieldEquivalent service configurationMeaning
reporepositoryHTTPS repository URL; otherwise inherited for repository services.
branchbranchSource branch.
runtimeruntimeauto or a supported runtime.
rootDirrootDirectoryBuild root relative to the repository.
buildCommandbuildCommandBuild command override.
startCommandstartCommandCommand for the running service.
preDeployCommandpreDeployCommandCommand before release; paid instance required.
staticPublishPathpublishDirectoryStatic build output directory.
schedulescheduleCron expression for a cron service.
planplanValid instance plan for the service kind.
configurationConfiguration mappingAdditional supported service configuration.

When the same setting appears both at the service top level and inside configuration, the top-level field wins. Avoid specifying a setting twice.

Configuration mapping

configuration accepts the service configuration fields defined in the public API specification. Common fields include:

FieldValues and constraints
sourceTyperepository, image, or none.
buildMethodrailpack, dockerfile, or image.
image, registryIdContainer reference and optional workspace registry UUID.
dockerfilePath, dockerContextRepository-relative Docker paths.
autoDeployoff, commit, or checks.
portInteger from 1 to 65535.
healthCheckPathEmpty or a path starting with /.
regionA region ID from the catalog.
replicas1–20, subject to service and plan constraints.
timezoneIANA timezone, such as Africa/Lagos.
timeoutSecondsCommand timeout; cron maximum is 43200.
databaseName, databaseUserSupported database/user identifiers.
databaseVersionPostgreSQL 16, 17, or 18; MySQL 8.4.
backupEnabled, backupRetentionDaysBackup settings for supported databases.

Paths cannot contain parent traversal or backslashes. Unknown configuration keys are rejected. Omitted settings use defaults on a new service and retain existing values during synchronization.

runtime: auto allows build detection. Other runtime values are docker, node, python, go, php, java, ruby, rust, elixir, deno, dotnet, gleam, cpp, static, and shell. Use Docker when your application needs dependencies or startup behavior outside an automatic build.

Plans

Application plans are free, starter, builder, growth, and scale. Free application instances are limited to web services and static sites, with a single replica and no paid-only settings.

PostgreSQL uses postgres-starter or postgres-standard. MySQL uses mysql-free, mysql-starter, or mysql-standard. MySQL Free is limited to one database per workspace. Read the catalog and current pricing before deploying a manifest containing paid resources.

Managed MySQL uses one private instance on port 3306 with sourceType: none. Repository build commands, HTTP domains, and auto-deploy settings do not apply to it. MySQL Free backup retention is 1–7 days; other database plans accept 1–30 days.

Secrets and other resources

Inline envVars values are rejected. An envVars entry without a value does not create or wire a variable. Use service variables or environment groups after configuration is created.

Render-specific directives such as fromDatabase, generateValue, sync, and top-level databases are not Openstead manifest features. Define databases inside services; configure variables, persistent disks, custom domains, and other service resources through their dashboard controls.

Validate

Use the dashboard's validation control or the CLI:

openstead blueprints validate --file openstead.yaml

Validation checks the manifest without provisioning resources. Applying or deploying still checks workspace quotas, source access, current entitlements, and service payment requirements.

Need a hand? Contact Openstead support.

On this page