Pricing
Size your cluster, see the price
Every cluster starts with a load balancer (IPv6 by default, with blocks of IPv4 addresses as an option). Then choose one, three, or five controllers. Add workers, encrypted NVMe, bulk HDD, and GPUs to fit your workload. The monthly estimate updates as you go.
Controllers
Addressing
Worker size
GPU workers
Your configuration
- LB, IPv6, management
- €240.00
- 3 controllers (HA) · S (2 vCPU, 8 GB)
- €324.00
- 3 × S (2 vCPU, 8 GB)
- €324.00
- NVMe 120 GB
- €10.80
Indicative pricing. The final quote follows a short sizing call.
Price list
Pricing for cluster resources
All cluster resources are billed per unit, at the same prices the configurator above uses. IPv6 is standard and data egress is free.
Legal
One jurisdiction, no third-party exposure
When models, applications, and data all run in the same Swedish data centre, your list of sub-processors gets short and the risk assessments get simple. Cyber security, legal review, DPIA. One environment to evaluate, one jurisdiction to reason about.
We run no cloud services underneath. Everything is processed on our own hardware in Sweden, within the EU, with no third-country exposure and no US CLOUD Act reach. Many teams come to us after concluding their data is too sensitive for the public cloud. They adopt our inference, and then ask where the application, the vector database, and the document store should live. The cluster is that answer. All of it in the same place, covered by the same assessment.
Fewer sub-processors to assess and audit
Sweden in the EU, with no US CLOUD Act exposure
Inference, applications and data under one assessment
Everything a production workload needs
Load balancer included
Every cluster ships with its own load balancer, IPv6-native with dedicated IPv4 blocks when you need them, plus Envoy Gateway ingress with automatic Let's Encrypt certificates against your DNS.
Encrypted NVMe storage
Block storage on NVMe, replicated to at least three physically separate disks. AES-256 at rest, TLS 1.3 in transit. Berget AI keys by default, customer-managed keys if you prefer.
Our own hardware, in Sweden
No hyperscaler reselling. Your cluster runs on machines we own, in two Swedish data centres, on read-only hardened node operating systems that carry no local state.
Network isolation by default
Customers are separated onto their own VLANs. Inside the cluster, namespaces inherit a deny-all NetworkPolicy baseline, with NeuVector watching runtime behaviour.
A registry that scans
The built-in Harbor registry CVE-scans every image with Trivy on push, and deployments pin images by digest. Non-root containers and restricted pod security standards are the default pattern.
Object storage on the inside
S3-compatible rustfs, reachable only from within the cluster network. Models, datasets, and backups never traverse the public internet.
FAQ
Questions and answers
Drawn from the procurement reviews we go through with public-sector and regulated customers.
Where does our data live, and can anyone outside the EU access it?
Our data centres are in Sweden and the hardware is owned by Berget AI. There are no third-country transfers or third-country access. No support staff, sub-processors, or parent company outside Europe. No exposure to the US CLOUD Act or FISA 702. The company is 100% European-owned. We never train on customer data. Prompts and outputs are never stored (zero data retention), and technical logs are kept for 30 days.
Can we sign a data processing agreement with the sub-processor chain listed?
Yes. The current DPA is at berget.ai/en/dpa. It supports the standard construction where you act as processor and Berget AI as sub-processor. It can be signed even for a sandbox/test environment. All our sub-processors are named and listed for your approval, and our DPO (dpo@berget.ai) is reachable for due diligence reviews. Customers also have audit rights, once per 12 months with 30 days' notice.
What certifications do you hold (ISO 27001, 9001, FR2000)?
We are actively working towards ISO 27001. The internal audit is the next step, and most of it is implemented in practice. ISO 9001/14001/FR2000 aren't on our roadmap. Available for due diligence today are the DPA, an 18-section TOMs security annex, Records of Processing Activities, and the ISO 27001 scope statement and statement of applicability (draft).
Is the Kubernetes managed? How are clusters and namespaces created?
Yes. We operate Kubernetes with GitOps (FluxCD). We run the control plane and updates. Clusters and namespaces are created and torn down through the Kubernetes API or GitOps, with Terraform support. All production changes go through pull requests with automated security review.
Which Kubernetes do we actually get?
A plain, upstream RKE2 cluster operated via Rancher, on minimal hardened SLES hosts with isolated VLANs. No forks and no proprietary lock-in layers. Anything that runs on Kubernetes runs here, and you manage workloads exactly how you prefer, with kubectl, Helm, Terraform, CI or our recommended GitOps flow.
Who operates what? Where does Berget AI stop and we start?
We run provisioning, upgrades, patching, security and monitoring of the clusters themselves. Your team deploys and runs its own workloads, via the Kubernetes API, Rancher UI, or GitOps, with self-service at namespace level and Terraform support for lifecycle management. You never touch node operations and we never touch your applications.
How are instances isolated from other customers, and how do we isolate internally?
Isolation per customer/project uses separate VLANs as standard, and storage per customer is in separate logical volumes with encryption available. How you separate your own team's namespaces inside your cluster is up to you. Kubernetes network policies let you restrict both traffic and accounts, designed by your team.
Can the platform manage Let's Encrypt certificates for our domains?
Yes. Every cluster ships with an Envoy Gateway ingress that handles automatic Let's Encrypt certificates via cert-manager against your public DNS names. The same pattern we use for our own services.
Do you support non-root containers, secrets handling and pinnable images?
Full support. Pod security standards (restricted) can be applied, and non-root containers are the norm. Secrets live in OpenBao (HashiCorp Vault fork) with least-privilege policies per cluster, fetched via Vault Secrets Operator. Plaintext secrets in Git, config, or env files are explicitly not allowed. Images are pinned by digest through Harbor with Trivy CVE scanning.
We already have a container registry. Why use yours?
You don't have to, but every cluster includes a Harbor registry that CVE-scans images with Trivy on push, so scanned images are already inside the cluster network. Deployments pin images by digest, so what you scanned is exactly what you run.
Do you offer managed databases (MongoDB, PostgreSQL or similar), and can we run our own in the cluster?
We don't operate managed database services. You run your own containers (MongoDB, PostgreSQL, TimescaleDB or anything else) inside your cluster. Data lands on encrypted PVCs (NVMe) automatically replicated to three physically separated disks. Keycloak runs fine in the same cluster with its own dedicated database. That's the production pattern in our own stack.
How do backups, snapshots, retention and object locking work?
Backup is the customer's responsibility. We provide the storage. Daily backups (CNPG base backups, Velero and volume snapshots) go to encrypted object storage you control, and we recommend the 3-2-1 pattern, with our S3 as the primary backup target plus an additional off-provider copy with your own credentials so you still have your data if our service were ever unreachable. Snapshots can be pulled out and scheduled exports configured. Retention is configurable, 30 days or less is supported, and regular restore drills are recommended.
Is object storage included?
Yes. S3-compatible rustfs runs in your cluster, reachable only from inside the cluster network. Datasets, model artefacts and backups stay off the public internet by construction.
What encryption is used at rest and in transit, and can we hold our own keys?
AES-256 at rest, TLS 1.3 in transit. PVC volumes are encrypted with customer-managed keys. We set up keys automatically, and you can swap in fully your own (BYOK).
What redundancy and availability zones do you have?
Two physical sites (sthlm-1 and sthlm-2), network-separated but close enough to run etcd across them. Clusters can span controllers and workers across both. More sites and zones are planned for Q1 2027.
What does the SLA and support look like?
The SLA is compensation-based. If unscheduled downtime exceeds 5 minutes, you get 50× the service fee for the interrupted period, calculated per affected cluster, capped at 30 days' fees per interruption and 2.5× the average monthly fee over a 12-month period. Claims within 15 days, and compensation is paid as credits. Scheduled maintenance is notified at least 24 hours in advance. Status is public at status.berget.ai. Our track record is there to inspect.
How do we get our data out, and how is deletion proven?
Full export in standard formats, including PVCs, object storage and database dumps, or kubectl cp straight from the volume without our involvement. Deletion is controlled by namespace deletion plus volume deletion, and a formal deletion certificate can be issued on request.
Do you have reference customers in regulated environments?
Yes. We serve customers with high security requirements, including regulated financial and defence-sector organisations. References are available on request, and we handle them individually based on each customer's approval.