← All topics

24 October 2026

Topic

Kubernetes hosting

Namespaces on the Colchester cluster. You run the pods. Broadbent keeps the cluster. 200 free hours, once per account.

Kubernetes hosting in Colchester

Kubernetes hosting on Broadbent Host is a namespace on the cluster we run in Colchester. You open one or more namespaces. You run the deployments, jobs, cron jobs, services and disks. We keep the cluster: setup and upgrades, the nodes, where each pod is placed, networking, load balancing, HTTPS ingress, the certificate when a domain points here, and the boundary around the namespace. Privileged and host-level options are removed. The bill covers every namespace on the account.

This is the service to order when the workload is already thought of as pods. A single site with a mailbox is still shared hosting. A machine with a login is a virtual server. One workload on a broadbent.app name is an app or a project. The long article is Managed Kubernetes in Colchester. The choice guide is Kubernetes or a virtual server. The order page is Kubernetes.

What is included

Cluster setup and upgrades are included. Placement of pods is included. Networking, the load balancer and HTTPS ingress are included. A certificate is issued once your name reaches the cluster. KEDA is installed, including the custom resources a ScaledObject and a ScaledJob need. You do not install KEDA, and the login cannot add a CustomResourceDefinition. The portal shows the pods, workloads, logs and disks, and it can restart or scale a deployment. Connect to namespace downloads a kubectl login for the namespaces you can use. It reaches k8s.broadbent.host.

Broadbent AI can read the namespace you have open and draft one kubectl command for the names it sees. If several match, it asks you to choose. Asking uses Broadbent AI credits. A shell or a port-forward is a command you run yourself. A viewer cannot change the namespace because a command was drafted.

What you bring

You open the namespaces. You decide who can see each one. You write the manifests. You put a request on every pod that must stay up. You point DNS with an A record or a CNAME. You watch the credit balance after the free hours. An account can hold several namespaces, such as production and staging. Each is separate from your apps and projects, and each running pod is metered.

The account owner sees the namespaces on the account. An admin, operator or viewer sees only the namespaces they were granted. A viewer can look at health, pods, disks and logs. An operator can change workloads. An admin can also manage access. Nobody can see another customer's namespaces. The login cannot list the cluster, the nodes or another customer, and it cannot open a shell.

Free hours

There are 200 free hours, once per account, claimed from the compute free hours order. They cover apps, projects and these pods. They are not reissued per namespace. While they last, each running pod, worker, job and cron job uses one hour of the allowance for every hour it runs. Disk is not billed yet. One pod is about eight days. Several pods use the allowance faster. After the hours, requests, burst and persistent disk are charged to the credit balance. An empty balance marks the namespace suspended.

Use the hours to prove a manifest. Put credit on the account before a production namespace is expected to stay up past that allowance. A cron job only spends hours while it runs. A replica that stays up spends them continuously. Scale-to-zero, through a scaler, spends them only while a replica is actually running.

The rates

Prices include VAT. CPU is £12.50 for a 730-hour month, five times the Compute CPU rate of £2.50. Memory is £1.50 per GB for that month. Disk is 6p per GB. The Kubernetes calculator stays flat on memory. Compute itself applies a small reduction above 4 GB, so 8 GB of Compute memory is £11.60. Compare like with like, on the page you mean to order. The header can show euros or dollars at the same catalogue ratio as Broadbent AI credit.

A request is the CPU or memory we keep for the pod. You pay the base rate for it for every hour the pod runs. Burst is only the amount above the request, and only for the hours of the peak. 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. Burst uses spare capacity. A new pod with a request is placed first. Burst is not guaranteed. Put what the workload must have into the request. A limit can cap the burst.

Persistent disk is billed, after the free hours, for as long as the claim exists. Files that live only inside the container are cleared when the container is replaced. The estimator on the page allows reserved CPU up to 32, reserved memory up to 128 GB, replicas from 1 to 8, and disk up to 100,000 GB. Those are form limits. Price the shape you will run, including staging.

Scaling

A ScaledObject changes how many replicas a deployment runs. A ScaledJob starts jobs. Either can follow CPU, memory, a schedule, or the depth of a queue or a database, from 0 to 20 replicas. Each running replica is billed like any other pod. 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. The hosted MariaDB is the managed database product, not a pod you hoped was reachable by a private IP in a different namespace.

From zero is useful for a worker that should exist only when the queue has work. The replica at zero is not a running pod and does not spend a free hour. The replica that wakes does. The database plan underneath does not grow because the scaler added pods. Database RAM is changed on the database plan.

Domains

Point the domain at the cluster. We issue the certificate when the name reaches us. On an app or a project you add the domain in the portal. In a namespace you put the hostname on an Ingress. Until DNS arrives, there is nothing to certify. If we host the DNS, the UK team can help with the records, as they do for other Host services. The Kubernetes page does not transfer the domain for you.

Who should order it

Order it for a web process plus a worker plus a job, with staging in a second namespace. Order an app or a project if there is one workload and you want the Compute CPU rate and a broadbent.app name. Order shared hosting for a Plesk site. Order a virtual or dedicated server if you want the machine. Order database hosting beside the namespace when MariaDB, PostgreSQL, MySQL, MongoDB or SQL Server 2022 Standard should be a managed instance with its own backups and address.

A month of 1.5 CPU and 3 GB reserved is £23.25 at the monthly rates, including VAT, before disk and burst. A 20 GB disk is £1.20 after the free hours. Three pods share the 200 hours and exhaust them in a few days. That is the bill to expect. The calculator on the product page is the version to use when your numbers differ. Claim the free hours once, set the requests, and keep a credit balance if the namespace has to stay up.

A layout that matches the bill

Picture two namespaces. Production holds a web deployment of two replicas, a worker, and a cron job for the night. Staging holds one web replica and its own disk. Ingress, the load balancer and the certificate sit in front of both, because those are part of what we keep. Every running pod spends free hours while the allowance lasts, so production's two replicas and worker are three concurrent pods before staging is counted. Add staging's pod and four things are spending the 200 hours. That is why a busy account sees the allowance disappear in a couple of days, and why the credit balance has to be ready.

Give each pod a request. A web replica that must answer gets the CPU and memory it needs in the request, not in a hope of burst. The worker gets its own request. The cron job gets a request too, and it is billed, or it spends free hours, only while it runs. Disk for uploads or a local cache that must survive a new pod is a persistent claim. A cache that can be rebuilt is not. After the free hours, the claim is billed for as long as it exists, at 6p per GB for a 730-hour month, including VAT.

Burst covers the peak above the request. Up to double is 125% of the base rate, on the extra amount, for the peak hours. Past double is 150%. A pod with an empty request is 150% the whole time it uses CPU or memory. Teams leave requests empty to "see what it costs" and then meet the unreserved band. Set the request to the steady load if you want the base rate. Set it higher if the peak is mandatory, because burst capacity is spare capacity and a new pod with a request is placed first.

Day to day in the portal

Open the namespace in the portal at portal.broadbent.group. You see pods, workloads, logs and disks. Restart or scale a deployment there when that is the whole change. Download Connect to namespace when you want kubectl. The file is for the namespaces you were granted. It talks to k8s.broadbent.host. It will not list nodes, and it will not open a shell. If a command needs a shell or a port-forward, that is your kubeconfig, run by you.

Ask Broadbent AI for a command in plain language when you know the outcome and want the names filled in. It reads the namespace you have open. If two deployments match, it asks which one before it writes the command. Read the command. A viewer still cannot apply it. Credits for Broadbent AI are separate from the Kubernetes credit balance that pays for pods after the free hours. An empty Kubernetes balance suspends the namespace. It does not send a separate story about why the site vanished. Watch the balance.

Point a domain when you want a name other than the one an app would have had on broadbent.app. An A record or a CNAME is enough for us to issue the certificate once the name arrives. In the namespace the hostname goes on an Ingress. On an app or a project the domain is added in the portal instead. Do not wait on the certificate before DNS works. The order is the other way round.

What stays outside the namespace

Mail stays on email hosting. The marketing site can stay on Plesk shared hosting. MariaDB or PostgreSQL that must have a dedicated IP, a shared virtual IP, and a backup retention you can name, stays on database hosting. The hosted MariaDB is the database a scaler is allowed to call, along with a service in the same namespace or a public host. SFTP backup, website maintenance and IT hours are still their own plans. A namespace does not patch WordPress, reset a laptop, or archive a mailbox.

Order this service from the Kubernetes page. Claim the 200 free hours once if the account has not claimed them. Put requests on the pods before you call the workload production. Read the article when you want the same rules written as a narrative, and the guide when you are still deciding between a namespace, an app, and a virtual server. The calculator on the product page is the arithmetic to trust when the example of 1.5 CPU and 3 GB is not your shape.

The portal, the kubectl file and the certificate are the parts to try during the free hours. A namespace you have not pointed a name at, and have not given a request, is not yet the service described on this page. Finish those two, then decide whether the credit balance should take over when the allowance ends.

Questions

What is included?

We keep the cluster, placement, networking, the load balancer, HTTPS ingress, certificates, and KEDA. You open the namespaces and run the workloads.

How do the free hours work?

200 hours, once per account. Each running pod, worker, job and cron job uses one hour for every hour it runs. Disk is not billed during those hours.

Contact

Speak to the team

Call our Colchester sales team, or send a message anytime.

UK sales team · 8:00am–8:00pm