Reviewing plan & cost

The Plan & cost tab of an instance runs a preview (POST /instances/:id/preview). The preview compiles the template with the instance's variables and placements, then compares the result with what OrkStage already knows about the instance. It never touches a cloud and saves nothing.

PlacementCopy Anchor Link

The preview lists every resource with the target, region and concrete capability it resolved to, for example database → Azure Database for PostgreSQL Flexible Server (eastus). When a capability is not available in a region, the preview fails and suggests alternatives.

PoliciesCopy Anchor Link

Every policy reports a result, so you see everything that was checked, not only what failed:

A fail result blocks the deployment. Custom templates go through the same policies.

Policies as dataCopy Anchor Link

The values behind these policies are data, set on Policies in the console or through the API:

• Platform staff set the platform policy (GET and PUT /policies). It applies to every tenant and is the only place where a built in policy can be turned off.
• Tenant owners and admins set their tenant's policy (GET and PUT /tenants/:id/policy). It can only tighten the platform policy: regions, sizes and registries narrow, budgets and replica limits go down, required labels add up, and the TLS version and log retention go up.

The page also shows the policy in effect for the tenant, which is what every preview and deployment is checked against. API keys cannot change policies.

{
  "allowedRegions": ["us-east-1", "sa-east-1"],
  "machineSizes": [{ "cpu": 0.5, "memoryMiB": 1024 }, { "cpu": 1, "memoryMiB": 2048 }],
  "approvedRegistries": ["123456789012.dkr.ecr.us-east-1.amazonaws.com/"],
  "requiredLabels": ["team"],
  "minTlsVersion": "1.3",
  "minLogRetentionDays": 90
}

Instance labelsCopy Anchor Link

Labels are key and value pairs on an instance, edited on its Overview tab or sent as labels when it is created or updated. They become tags on every cloud resource of the instance, next to the platform tags (which win on a clash and whose platform prefix is reserved). A policy can require some of them, for example team, so every resource can be traced to its owner and cost center.

ConnectivityCopy Anchor Link

For each connectivity requirement in the template, the compiler chooses a strategy:

OrkStage never creates VPNs or interconnects without telling you. Links between clouds add latency and may incur egress charges, and the preview says so.

What OrkStage wires for a link between cloudsCopy Anchor Link

The plan shows, for each link between clouds, what OrkStage does besides choosing the strategy:

Cross-cloud
  CONFIGURE api → database (public-tls-allowlist); credentials copied to api's secret store; firewall allows network egress only

• Credentials. When the consumer runs on AWS, Azure or Google Cloud and the database lives on another provider, OrkStage reads the database credentials from the provider that owns them and copies them into the consumer's own secret store at deploy time: one Secrets Manager secret on AWS, Container Apps secrets on Azure, Secret Manager on Google Cloud. The service receives them as <ID>_USERNAME, <ID>_PASSWORD and so on. The values pass to OpenTofu as a sensitive variable and never appear in the stored configuration. On other providers the service receives only the reference, <ID>_CREDENTIALS_REF, and reads it at start.
• Allowlist. For public-tls-allowlist, the database waits for the consumer's network and its firewall allows only that network's egress addresses: Azure PostgreSQL firewall rules (replacing the rule that admits every Azure service) or Cloud SQL authorized networks. The network needs a NAT gateway (natGateway: true) for a fixed egress address; the plan says so when it has none. PostgreSQL on AWS and OCI has no public endpoint, so a consumer on another cloud cannot reach it without a VPN or interconnect, and the plan says that too.
• Verification. After the deployment, each link is reported with its wiring and whether both ends are healthy. The worker sits in neither network, so it does not probe the path between them; check it from the application (a connection test at start) when it matters.

Cost estimateCopy Anchor Link

The estimate uses static list prices from each capability catalog (on demand, monthly, in USD). It is always labeled approximate and is not an invoice. Its confidence is approximate when every resource has a price, partial when some do not, and unavailable when none do. Lines are grouped by category: compute, database, cache, storage, network and messaging.

The plan and its riskCopy Anchor Link

The diff against known resources lists each resource as CREATE, UPDATE, DELETE or NOOP, grouped by provider, target and region. A change of target, region or capability counts as a replacement. Approval requests and logs use the same plan in plain text:

Deployment Plan

Instance: Acme Production

AWS / aws-prod / us-east-1
  CREATE Amazon VPC network
  CREATE Amazon ECS on Fargate api
  CREATE Application Load Balancer ingress

AZURE / azure-data / eastus
  CREATE Azure Database for PostgreSQL Flexible Server database

Cross-cloud
  CONFIGURE api → database (public-tls-allowlist)

Risk: low

The preview shows the platform's view. During the deployment, the worker also runs the real provider plan for each resource that changes. See Deploying.