Deployment Tiers
Honeyframe ships in three deployment tiers. The product is the same across all three — same UI, same recipes, same connectors. What changes is who runs the infrastructure underneath.
Choose your tier
| Tier | Who runs the infra | Best for | How to get it |
|---|---|---|---|
| Honeyframe Cloud | We host it on our infrastructure | Teams that want to start fast without provisioning servers — pilots, evaluations, small deployments | Sign up at app.honeyframe.io (invite-driven in v0.0.39; public Launchpad self-serve lands in v0.0.40+), click Create Space, pick a region |
| Honeyframe Enterprise | Customer's own cloud account (BYOC), we deploy and manage | Enterprises with data-residency, procurement, or networking constraints that require Honeyframe to live inside their cloud | Contact sales — engagement-led |
| Honeyframe Self-Hosted | Customer, on-prem or their own VM | Air-gapped environments, regulated industries, or teams that need full operational ownership | Tarball + license file + setup-customer.sh |
What you get is the same
Every tier provisions a Space — a managed Honeyframe instance scoped to your organization. A Space contains your projects, datasets, recipes, dashboards, users, connections, and dbt models. Whether the Space runs on our infrastructure (Cloud), in your cloud account (Enterprise), or on your own server (Self-Hosted), the application layer is identical.
This means you can start on Cloud, outgrow it, and migrate to Enterprise or Self-Hosted later without rewriting recipes or rebuilding dashboards. Project export/import is preserved across tiers.
What this manual covers
This Documentation section is written primarily for Self-Hosted, because Self-Hosted operators need every detail — system requirements, reverse-proxy config, TLS, LDAP, systemd units, license activation, and so on.
If you are on Honeyframe Cloud, most of the Installation chapter does not apply to you — we run the install for you. Skip to Connectors, Datasets, and Recipes to start building.
If you are on Honeyframe Enterprise, your account team will have already deployed Honeyframe into your environment. Use this manual to understand operational behavior; defer infrastructure changes to your account team.
Engine profile: dbt vs native
Independent of the deployment tier, every organization is provisioned with an engine profile that selects the transformation engine recipes compile against:
| Profile | Transformation engine | When to pick it |
|---|---|---|
dbt (default) | dbt — full incremental models, snapshots, macros, tests | Existing dbt workflows; teams that already own dbt projects. |
native | A built-in SQL engine — CREATE TABLE AS / CREATE OR REPLACE VIEW straight against the tenant warehouse (Postgres + DuckDB), full-refresh tables and views only | Lean installs that don't want a dbt toolchain. The native engine has no dbt binary dependency, so the install skips the dbt pip-install, profiles.yml, and the dbt-run timer entirely. |
The profile is stored in organizations.engine_profile (CHECK (engine_profile IN ('dbt','native'))) and defaults to dbt, so existing installs are byte-identical. For self-hosted, set it at install time with ./iaas/scripts/setup-customer.sh --engine native (or engine_profile: native in install.conf) to provision a tenant born native. On Cloud/Enterprise, POST /api/organizations accepts engine_profile at org-creation time.
Switching an existing org to native is guarded: PUT /api/catalog/engine returns 409 if SQL-shaped recipes in the org aren't native-runnable (use ?force to override). Flipping back to dbt is unguarded. Anything beyond full-refresh tables/views — incremental models, snapshots, macros, tests — stays on the dbt engine.
Common questions
Can I move between tiers?
Yes. Spaces are portable: project bundles, recipe definitions, dashboards, and dbt models all export to a tier-agnostic format. The data underneath your connectors stays where it is — Honeyframe doesn't move your warehouse. Migrating tiers means standing up a new Space on the target tier and re-pointing connections.
Is Honeyframe Cloud multi-tenant?
The Cloud tier runs as shared multi-tenant on our managed Honeyframe install — same architectural pattern as PostHog / Linear / Notion. Each Space is one row in honeyframe.organizations with strict per-org access control: dashboards, datasets, recipes, and connector credentials are scoped to your org and never visible to another tenant. The org-isolation Row-Level Security scaffolding shipped in v0.0.38 covers data_connectors and pipeline state; additional surfaces are migrating in subsequent releases.
The Enterprise tier is the opposite — every Space is a fresh per-VM install, fully isolated at the OS layer. Self-Hosted is also one install per customer.
If your compliance posture requires "no shared infrastructure with other customers" (HIPAA in some interpretations, FedRAMP, banking on-prem mandates), pick Enterprise or Self-Hosted. The Cloud tier is the right choice for SMB pilots and self-serve evaluation.
What region is Honeyframe Cloud hosted in?
At launch: Jakarta (Indonesia). Additional regions will be added based on customer demand. Enterprise tier customers choose their own region — it's their cloud account.
How does pricing work?
Cloud has self-serve pricing (free trial → paid tiers). Enterprise and Self-Hosted are both license-based — contact sales for a quote tied to your seat count and node footprint.
Where to next
- New to Honeyframe? Read the Overview and try Quickstart.
- Installing Self-Hosted? Start with System Requirements and Standard Install.
- Already have a Space? Jump to Connectors to bring in your first dataset.