The application definition answers one question: what must remain true about this application regardless of where it eventually runs?
A multi-capability application.
contract_version = "0.1"
[application]
name = "orders"
version = "1.0.0"
description = "Example order-processing application"
[[workloads]]
name = "api"
kind = "component"
[[workloads]]
name = "worker"
kind = "component"
[[interfaces]]
name = "jobs"
kind = "event"
[[relationships]]
from = "api"
to = "worker"
interface = "jobs"
[[capabilities]]
interface = "presolve:kv/store"
version = "^0.1"
[[capabilities]]
interface = "presolve:objects/store"
version = "^0.1"
preferred_features = ["range-read"]
[[capabilities]]
interface = "presolve:sql/database"
version = "^0.1"
[[capabilities]]
interface = "presolve:queue/work-queue"
version = "^0.1"
[resources]
memory_mib = 256
cpu_millis = 500
[network]
outbound = "deny"Nothing above selects Redis, PostgreSQL, S3, Cloudflare, a filesystem path, a cloud account, or a deployment region. Those are environment/runtime concerns.
What the application definition can express.
| Section | Purpose | Examples |
|---|---|---|
[application] | Stable application metadata | name · version · description |
[[workloads]] | Logical executable parts of the app | Component · container |
[[interfaces]] | Application-local communication semantics | request_response · event |
[[relationships]] | Topology between workloads | api → worker over jobs |
[[capabilities]] | External service/behavior requirements | KV · objects · SQL · queue |
[resources] | Minimum runtime requirements | memory_mib · cpu_millis |
[network] | Outbound application policy | deny · allow_list · allow_all |
Logical execution units belong to the application.
A WebAssembly Component workload. Component artifacts can be embedded directly in the built release.
An OCI-compatible workload whose immutable descriptor identity is represented by the release without embedding registry location or credentials.
Artifact build paths, registry URLs, placement, node names, and provider configuration do not belong in the application definition.
Declare service semantics and version compatibility.
[[capabilities]]
interface = "presolve:sql/database"
version = "^0.1"
optional = false
required_features = ["dialect-postgresql"]
preferred_features = ["returning"]required_features are hard compatibility constraints. preferred_features influence provider ranking but do not make an otherwise-compatible environment invalid. optional = true permits a capability to remain unbound.
Describe relationships without choosing transport.
eventThe relationship says the application has this communication shape. It does not require HTTP, a queue product, a service mesh, or another transport unless those semantics are separately declared.
Outbound access is application intent.
[network]
outbound = "allow_list"
allow = ["api.example.com", "storage.example.com:443"]Targets are hosts or host-and-port values, not URLs. The default is deny.
What belongs here?
- workload classes
- service/capability requirements
- required/preferred semantic features
- minimum resource requirements
- network policy
- application-local topology
- environment selection
- provider IDs
- provider credentials
- service endpoints
- database paths
- registry location or placement
presolve.toml even though the application's behavior and requirements did not change, that is a portability-boundary smell.Invalid application definitions fail loudly.
Unknown fields are rejected. Presolve validates naming, workload and interface references, capability identifiers/versions/features, resource values, network policy, duplicate declarations, and topology invariants before normalization.
presolve inspect
presolve build
presolve check
presolve plan