Your application can ask for storage, SQL, queues, and other services without making one provider part of the application itself.
Developer Preview
Build once.
Decide where it runs later.
Presolve lets you build an application without baking a specific cloud, database, or storage provider into it. Build it once, then check where that exact build can run and what infrastructure it will use.
presolve
$ presolve build
release: dist/orders.presolved
digest: sha256:8f6d…
$ presolve check dist/orders.presolved
Status: compatible
$ presolve plan dist/orders.presolved
key-value storage → cloudflare-kv
sql database → postgres-sqlWhy Presolve
Infrastructure can change without turning your app into a different build.
Presolve separates what your application needs from the specific service that provides it.
Presolve tells you whether an environment can satisfy the application and reports what is missing when it cannot.
Move the same packaged application between environments instead of rebuilding it just to switch infrastructure.
The workflow
Four commands. Four useful answers.
You can use Presolve without learning its internal architecture first.
presolve inspectWhat does my application need?See the application Presolve understands before choosing an environment.
presolve buildWhat am I distributing?Create the packaged application that can be checked against different environments.
presolve checkCan it run here?Verify that the current environment can provide everything the application requires.
presolve planWhat will it use?See the exact runtime and providers Presolve selected before execution.
The portability proof
Same application file. Different infrastructure.
Presolve's flagship proof builds the application once, keeps the release digest unchanged, and checks that same file against materially different environments.
built oncekv-demo.presolved
sha256: unchangedLocalin-memory KV
Network serviceRedis
Managed cloudCloudflare KV
Under the hood
The app says what it needs. The environment says what it has. Presolve matches them.
This is the formal model behind the simple workflow above. You only need these terms when you want to go deeper.
Your application
presolve.toml- what code should run
- which services it needs
- resource needs
- network intent
P
Presolvechecks + matchesTarget environment
presolve.env.toml- where code can run
- available providers
- resource capacity
- provider identities
resultDeployment plan
the exact workload and provider choices Presolve madeAvailable today
This is working software, not a portability mockup.
Presolve is still pre-stable, but the core build, compatibility, planning, provider, and proof paths are implemented and checked in public CI.
Create deterministic .presolved packages from supported authoring paths.
Detect when an environment cannot provide something the application requires.
See the providers and versions selected before runtime objects are created.
Current implementations include memory, Redis, Cloudflare KV, S3-compatible storage, SQLite, PostgreSQL, and queues.
WebAssembly Components and OCI/container workload identity and execution paths are represented.
KV, object-storage, SQL, and queue checks exercise portability and semantic compatibility.
Start with the workflow. Dig into the architecture when you need it.
Presolve is developed in public under Apache-2.0. Run the tutorial, inspect the proof, and tell us where the portability model fails under real infrastructure.