Managed Kubernetes in Colchester
Managed Kubernetes on Broadbent Host is a namespace on a cluster we already run in Colchester. You open one or more namespaces and put deployments, jobs, cron jobs, services and disks in them. We keep the cluster: the nodes, the upgrades, the networking, the load balancing, the HTTPS ingress, and the boundary around each namespace. You do not rent a control plane, and you do not get a login that can list the nodes or another customer's namespaces.
That split is the whole product. An app or a project on Compute runs one workload and is priced on its own. Managed Kubernetes is the suite. The same account can hold production, staging, and another environment, and every running pod in those namespaces is metered. The portal for it is at portal.broadbent.group, under the account's Kubernetes section. A published app or project can also sit at a name on broadbent.app, with HTTPS, when that is the shape of the workload.
This page is the long version of how that works. The order page, the rate card and the questions on Kubernetes are the source. Where a figure is quoted here, it is the figure on that page, in pounds, including VAT. The header on the site can show the same catalogue in euros or dollars at the Broadbent AI credit ratio. The calculator on the Kubernetes page is the place to try a shape before you leave anything running.
What you open, and what we keep
You open the namespaces. You choose who on the team can see each one. You write the manifests. You point a domain at the cluster. You watch the namespace in the portal. Those are the parts marked as yours on the Kubernetes guide.
We keep cluster setup and upgrades. We place pods on the nodes. We provide networking, load balancing and HTTPS ingress. When a domain points at the cluster, we issue the certificate. Each namespace has a boundary. Privileged and host-level options are removed, so a manifest cannot take the node. We also install KEDA and the custom resources a scaler needs, and we produce the bill across every namespace on the account.
The cluster is one cluster. The picture on the product page is a production namespace with a web deployment, a worker and a nightly job, next to a staging namespace with its own web deployment and a disk. Ingress, the load balancer and the certificate sit in front of both. That is the shape to plan for: more than one namespace is normal, and every namespace on the account is metered.
A viewer can look at health, pods and disks, including pod logs. An operator can change workloads. An admin can also manage who has access. The account owner sees the namespaces on that account. Nobody can see another customer's namespaces. A viewer still cannot change the namespace, even if Broadbent AI is asked to write a command.
An app, a project, or a namespace
Deploy an app from files, or a project from an image, when the thing you are running is one workload. CPU on that path is the Compute rate, £2.50 for a full month of one CPU. The namespace path is for the case where you want deployments, jobs, cron jobs and disks together, and you may want more than one environment. CPU on managed Kubernetes is £12.50 for a 730-hour month of one CPU, five times the Compute CPU rate, including VAT, for every pod in every namespace.
Memory on Kubernetes is £1.50 per GB for that same 730-hour month. Disk is 6p per GB. Memory matches the Compute memory rate at the base, and disk matches Compute. Above 4 GB, Compute applies a small memory reduction, so 8 GB of Compute memory is £11.60. The Kubernetes calculator stays flat: it does not apply that reduction. If you are comparing a large memory footprint, use the calculator on the page you intend to order, not a blended guess.
The 200 free hours are once per account. They cover managed Kubernetes as well as apps and projects. You claim them from the order page for compute free hours. They are not a fresh allowance for each namespace, and they are not a fresh allowance because you also deployed an app.
How the 200 free hours are spent
While free hours remain, each running pod, worker, job and cron job spends one hour of that allowance for every hour it runs. Disk is not billed yet. Several pods use the allowance faster than one pod. One pod is about eight days. Two replicas of a web deployment, plus a worker that stays up, are three running pods, so the same 200 hours last a little under three days if all three stay up the whole time. A cron job only spends an hour while that job is running.
After the hours are used, every pod request, any burst, and every persistent disk is on the bill. Managed Kubernetes then comes off your credit balance. An empty balance marks the namespace suspended. That is the pause. It is not a separate overage invoice described on the page. Keep an eye on the balance if the namespace has to stay up past the free hours.
Free hours are a good way to prove a manifest. They are a poor way to run a busy production namespace for a month, because the allowance is shared and it is counted per running pod. If you already know the request sizes, price the month on the calculator before the free hours run out, so the credit balance is there when the allowance ends.
Requests, burst, and a pod with no request
A request is the CPU or memory reserved for a pod. We keep it available, and you pay the base rate for it for every hour the pod is running. On a full month that is £12.50 per CPU and £1.50 per GB of memory, including VAT. The hourly rate is that monthly figure divided by 730. The calculator clamps a reserved CPU between 0 and 32, reserved memory between 0 and 128 GB, and replicas from 1 to 8. Those are the bounds of the estimator, not a promise that every size in between is a separate plan.
Burst is only the amount above the request, and only for the hours that peak lasts. Up to double the request, the extra is at 125% of the base rate. Past double, the extra is at 150%. A pod with no request is at 150% for the resource it uses, for the hours it is active. A request of zero CPU with some CPU actually used is the unreserved band. If the pod uses nothing, that line is not a charge.
Burst uses spare capacity. A new pod that has a request is placed first. Put anything the workload must have into the request. A limit can stop a pod bursting past a ceiling. Burst capacity is not guaranteed. If a job can wait, a request that matches the steady load, plus a limit, is the calmer bill. If a web pod must answer during a spike, the spike belongs in the request, because the request is the part we keep.
Replicas multiply the pod. Two replicas with the same request are two running pods. Each one spends a free hour while the allowance remains, and each one is billed from its own request afterwards. A nightly job is billed for the time it ran, not for the rest of the day. A cron job that exits is not a replica that sits there all month.
Disk
Persistent disk is 6p per GB for a 730-hour month, including VAT. It is not billed while free hours remain. After that, the claim is billed for as long as it exists, whether or not a pod is writing to it. The estimator allows a claim up to 100,000 GB. That is the cap on the form. It is not a stocked volume you should assume is sitting free.
Files that exist only inside a container are cleared when the container is replaced. If a database, a queue or an upload directory has to survive a new pod, it has to be a persistent claim. If it is a cache that can be rebuilt, leave it off the claim and you are not paying for that disk after the free hours. The staging namespace on the product diagram is the usual place a disk shows up next to a web deployment. Production and staging claims are both on the bill. They are not one shared disk unless you make them one.
Scaling with KEDA
KEDA is already installed on the cluster, including the custom resources a ScaledObject and a ScaledJob need. You add one of those in your namespace. You do not install KEDA, and the login cannot add a CustomResourceDefinition. A ScaledObject changes how many replicas a deployment runs. A ScaledJob starts jobs. Either one can follow CPU, memory, a schedule, or the depth of a queue or a database, from 0 to 20 replicas.
The trigger may call a service in that namespace, such as db or redis:6379, the hosted MariaDB, or a public host. A private address and another namespace are refused. That rule matters if the database is the managed database product rather than a pod in the same namespace. The hosted MariaDB is an allowed host. A database you reached by a private address in a different namespace is not. Each replica that is running is billed like any other pod, including a replica that scales from zero when the queue has work and back to zero when it does not. A replica at zero is not a running pod.
From 0 to 20 is the range on the page. It is not an extra charge for the scaler itself. The charge is the pods that are actually running, at the request and burst rules above. A schedule that wakes a job overnight spends free hours, or money, only while that job runs.
The portal, kubectl, and Broadbent AI
In the portal you see the pods, workloads, logs and disks. You can restart or scale a deployment. Connect to namespace downloads a kubectl login for the namespaces you can use. It reaches k8s.broadbent.host. The login cannot list the cluster, the nodes, or another customer, and it cannot open a shell. Privileged and host-level options are removed. A viewer can look, including pod logs. An operator or an admin can change workloads.
Broadbent AI reads the namespace you have open: the pods, services, ports, addresses and disks. Ask in plain language and it writes one kubectl command for those names. If several match, it asks you to choose before it writes the command. Asking uses your Broadbent AI credits. A shell or a port-forward is a command you run yourself with the kubeconfig. The assistant does not open a shell for you, and a viewer still cannot change the namespace because the assistant wrote a command.
That is a useful limit. The command is built from the names already in the namespace, so it is less likely to point at the wrong deployment. It is still a command. Read it before you run it, the same way you would read a manifest.
Your own domain
Point the domain at the cluster with an A record or a CNAME. We issue the certificate once the name reaches us. On an app or a project, add the domain in the portal. In a managed namespace, put the hostname on an Ingress. The certificate is one of the things we keep. You do not upload it, and you do not run a separate certificate pod unless you have a reason of your own.
DNS itself is still yours to point. If the domain is registered with us, the UK team can help with the records, as they do for other Broadbent Host services. The Kubernetes page does not move the domain for you. Until the name reaches the cluster, there is no certificate to issue.
When this is the wrong product
A brochure site on shared hosting does not need a namespace. Plesk on that plan already has the site, mail and the usual PHP tools. A single virtual server is the right size when you want a machine, a login and a process list, and you do not want to write manifests. A dedicated server or a co-located machine is the right size when you need the whole box. The Kubernetes CPU rate is deliberately higher than the Compute CPU rate because you are paying for the namespace, the placement, the ingress and the boundary, not for one container at the app rate.
Use the namespace when you have more than one process that should scale on its own, a job that should exist only while it runs, or a second environment that must stay separate. Use an app or a project when there is one workload and the Compute rate is the one you want. The guide on this site, Kubernetes or a virtual server, walks that choice without repeating the rate card line by line.
A month, written out
Take a production namespace with two web replicas, each requesting 0.5 CPU and 1 GB of memory, a worker requesting 0.5 CPU and 1 GB, and a 20 GB disk. That is 1.5 CPU and 3 GB reserved while those three pods run, plus the disk. At the monthly rates, 1.5 CPU is £18.75 and 3 GB is £4.50, so the reserved compute for a full 730-hour month is £23.25, and 20 GB of disk is £1.20, including VAT, before any burst. If those three pods run through the free hours first, the 200 hours are shared across three running pods and last on the order of two to three days, and the disk is not billed until the hours are gone. Burst on top of the request is extra, only for the extra amount and only for the peak hours. This is the same arithmetic as the calculator. If your replicas, hours or disk differ, use the calculator rather than scaling this example by hand and hoping the bands match.
A staging namespace with one small web pod and its own disk is a second bill on the same account. It also spends free hours while its pod is running. Teams often forget staging when they price production. The product counts every namespace.
Nothing on this page changes the order. Open the namespace from the Kubernetes product, claim the free hours once if the account has not claimed them, and put a request on anything that must stay up. The questions at the bottom of the Kubernetes page are the short form of the same rules: what is billed, who can see a namespace, how a domain gets a certificate, and what happens when the balance is empty.