A control plane for dbt Core, on your own infrastructure.
Scheduling, slim CI, alerts, run history and an audit trail - as one static binary and one config file. Your warehouse credentials stay in your installation, and so does every row they touch.
Built for one specific moment
The moment your team needs a 6th builder or a 2nd project, and the next step up stops being a price change and becomes a procurement project.
You already run dbt Core
The models, the tests and the CI logic are yours. What you are paying for is orchestration - and that is the part you can host yourself.
Seat limits drive the upgrade, not features
Being pushed into an annual contract and a committee because one more analyst joined is a bad reason to change vendors.
Viewers should be free
Everyone who only reads run history, docs and test results is unlimited in every tier. You pay for people who build.
What it does
Everything listed here has been exercised end to end on a real server against a real warehouse, a real GitLab CE instance and real github.com - not only in unit tests.
Scheduling that survives downtime
Cron with an explicit timezone, a persisted tick, and a policy for what to do about missed windows and overlapping runs. A restart mid-run re-attaches to the live container instead of losing it.
Slim CI that defers the rest
A merge request builds the models that changed and defers everything else to the production manifest, into its own target schema. Fewer models recomputed is a smaller warehouse bill, which is the point.
Draft pull requests do not build
A PR opened in the morning and pushed to ten times is one build when it is marked ready, not ten. Verified on both GitHub and GitLab.
Native status in your git host
A GitHub Check Run and a GitLab commit status per environment, plus one merge-request comment updated in place with a per-model table and the name of the test that failed.
Per-model results, not just a log
Run history keeps every state transition and every model outcome parsed from run_results.json, so "when did this model start getting slower" is a question you can answer.
dbt docs behind your SSO
The docs site from the last successful production run, served to unlimited viewers and only to people who are logged in.
SSO, roles and an audit trail
Log in through your identity provider over OIDC. Three roles, API tokens, and an audit log of who changed which account, token, integration or licence - exportable as CSV or JSON.
Alerts with a reason attached
Slack or a webhook, sent once at the end of a retry chain rather than on every attempt, naming the failure category and linking straight to the run.
Backups you can prove
Continuous replication with point-in-time restore. The process warns you when replication has stalled or when the master key no longer opens your secrets - in the first second of its life, not the morning you need the backup.
Zero data access, by architecture
This is the claim a self-hosted vendor has to be able to defend, so here is the mechanism rather than the adjective.
| Question | Answer |
|---|---|
| Where do runs execute? | In containers on your machine, started by your installation. The vendor has no endpoint in that path. |
| Where do warehouse credentials live? | Encrypted in your database with a master key kept outside it. They are decrypted into the run container and stripped out of the log stream. |
| Does the product call home? | No. The licence key is verified offline with an Ed25519 signature. An installation with no outbound internet access works. |
| What does the vendor receive? | Nothing automatic. No telemetry, no metadata upload, no hosted component in the run path. |
| What runs it? | One static binary and one config file, with SQLite as the default database. No broker, no extra stateful service to operate. |
The whole installation
One binary, one key, one config file. The demo flag creates a sample project and runs it, so the first thing you see is a green run rather than an empty screen.
# the master key encrypts your secrets - keep it, nothing decrypts without it export MONOPLANE_MASTER_KEY_FILE=/etc/monoplane/master.key # shortest path to exercising the whole thing end to end monoplaned -demo-git-url https://github.com/your-org/your-dbt-project # after that, an ordinary start monoplaned -config /etc/monoplane/monoplane.json
Where the product actually stands
Monoplane has not had a tagged release yet and is not open for self-serve signup. Saying so is cheaper than being found out, and if you are evaluating orchestration you need the real state, not the brochure.
Read this before you plan around it
- No public release yet. There is no version tag and no binary download on this page. Early installations happen with us in the room.
- One-click import from dbt Cloud is not ready. The code exists and reads configuration only, but it has never run against a real dbt Cloud account, so we do not demo it and you should not count on it.
- PostgreSQL is not supported yet. SQLite is the default and the only driver today. It is a deliberate choice for a single-instance install, and it is the wrong answer if you need high availability on day one.
- Source-available, not open source. The licence is the Elastic License 2.0: read it, run it, modify it, but do not resell it as a managed service.
- Extraction and loading are out of scope. No source connectors. Monoplane orchestrates dbt; it is not an ELT platform.
How pricing is shaped
Flat per tier, with no consumption component - your bill should not move because a backfill ran. Exact figures come up in the first conversation, because we would rather hear what this is worth to you than publish a number we picked ourselves.
| Tier | Who it is for | What it includes |
|---|---|---|
| Free | Up to 5 builders, one project | Scheduling, slim CI, run history, alerts, docs. Not a trial - it does not expire. |
| Team | The team that just hit the limit above | Unlimited projects, models and runs. OIDC single sign-on. Priced to be bought without a committee. |
| Scale | Formal security review in the way | Audit-log export, air-gapped operation, priority support. SAML, SCIM and fine-grained RBAC are on the roadmap, not shipped. |
Talk to us
We are looking for a small number of design partners: teams running dbt Core who feel the seat limit. You get the product early, a permanent discount and a direct line to the person building it. We get to find out where it breaks on infrastructure that is not ours.