Dedicated Tenant and Self-Host
Most teams use SemanticFed as a managed multi-tenant service. Organizations with stricter isolation, sovereignty or procurement requirements have two further options.
Dedicated tenant (Enterprise)
A dedicated tenant is a complete SemanticFed environment that serves only your organization. It runs the same software and receives the same releases as the managed service, but nothing in it is shared with any other customer.
What is dedicated to you
- Network: its own AWS VPC, load balancers and public hostname (for example
yourcompany.semanticfed.com) - Compute: its own Kubernetes clusters for the API gateways, identity, access control and SemanticFed services
- Data: its own PostgreSQL databases for your models, policies, saved queries and run history, with its own encryption keys (your own AWS KMS key on request)
- Secrets: its own AWS Secrets Manager store for service configuration and the credentials you register for your sources
- Operations: its own backups, monitoring and release schedule — track every release, or pin releases for change control
Where it runs
| Variant | AWS account | Good fit when |
|---|---|---|
| Managed dedicated | A dedicated account operated by SemanticFed | You want isolation without running anything yourself |
| Your-account dedicated | Your own AWS account, with a deployment role you grant to SemanticFed | Keys, logs and infrastructure must stay inside your account boundary |
You choose the AWS region. SemanticFed operates the software in both variants: deployment, upgrades, monitoring, backups and incident response.
Reaching your sources privately
Because SemanticFed queries your data in place, a dedicated tenant can connect to your sources over VPC peering, AWS Transit Gateway or AWS PrivateLink, so source traffic never crosses the public internet. Only the access-policy-filtered query results leave the source.
How it is delivered
Dedicated tenancy is part of an Enterprise agreement. Provisioning lead time, sizing, region, release policy and private connectivity are agreed in the order form. Before handover, the environment passes the same end-to-end checks that gate every production release.
Self-host and air-gapped (roadmap)
A packaged, customer-managed install is in development for organizations that must run SemanticFed on their own Kubernetes cluster or in a disconnected (air-gapped) network:
- Signed container images and a Helm chart, with database migrations applied automatically at start-up
- No dependency on hosted SemanticFed services at runtime: the API schema ships with each release
- Your own secrets backend — AWS Secrets Manager, HashiCorp Vault or an equivalent — through the External Secrets Operator
- Offline license verification and signed release bundles for air-gapped networks, with no telemetry sent outside your boundary
Until it ships, a dedicated tenant in your own AWS account is the way to keep SemanticFed inside your account boundary.
Comparing the options
| Multi-tenant SaaS | Dedicated tenant | Self-host (roadmap) | |
|---|---|---|---|
| Operated by | SemanticFed | SemanticFed | Your team |
| Infrastructure shared with other customers | Yes, with workspace isolation | No | No |
| Region | SemanticFed's region | Your choice of AWS region | Your choice |
| Private connectivity to sources | Allow-listed egress | VPC peering, Transit Gateway, PrivateLink | Inside your network |
| Release schedule | Continuous | Continuous or pinned | You decide |
| Plans | All | Enterprise | Enterprise |
To discuss a dedicated tenant or join the self-host early-access list, contact [email protected].