Which one to order
There are four honest answers on Broadbent Host, and only one of them is Kubernetes. A site that is a few pages and a mailbox belongs on shared hosting with Plesk. A machine you want to log into, with a process list and root on the self-managed plans, is a virtual private server. A whole machine in the Colchester data centre is a dedicated server. A namespace of deployments, jobs and cron jobs, on a cluster we already run, is managed Kubernetes. This guide is the choice. The long description of the rates is the article Managed Kubernetes in Colchester.
Start from the thing you are running, not from the product you have heard of. If you cannot name a second process that should scale on its own, you probably do not want a namespace yet. If you cannot name why root access would help, you probably do not want a virtual server yet. If the site is WordPress and the mail is a handful of mailboxes, shared hosting is the match.
Shared hosting
Standard and Premium are Plesk. The panel includes WordPress Toolkit, SEO Toolkit, PHP Composer, Git, Softaculous and Security Advisor. You do not patch the server. You do not write a manifest. Website maintenance is not included. A domain can be bought with the hosting or pointed from a name you already own. Mail can live on the same account, with the limits of the hosting plan, or on the email plans.
Choose this when the success of the project is a page that loads and a mailbox that receives. Leave it when you need a dedicated database address, a replica, a private network, or a process that is not a PHP site. Stretching shared hosting until it falls over is more expensive than moving earlier, because the move happens during the fault.
A virtual server or a dedicated server
A virtual private server in the Colchester data centre can be managed or self-managed. Self-managed plans include root access. Plans can be upgraded or downgraded. A dedicated server is a whole machine in the same facility, managed or self-managed, with backup power and A+B redundancy. Co-location is your own equipment in that facility, from a quarter rack to a full rack, with remote hands charged separately.
Choose a virtual server when you want a familiar Linux login, a service you install yourself, and resources that are yours rather than a slice of a shared Plesk account. Choose dedicated when the workload or the compliance conversation needs the whole machine. Choose co-location when the hardware is already yours. On a dedicated server or a Raspberry Pi server you may install Plesk, Interworx, or leave the machine bare. That panel is optional. On shared hosting it is the product.
These machines are not billed like Kubernetes. You are not paying £12.50 per CPU for a requested pod, and you are not spending the 200 free hours per running pod. You are renting the server. You are also the person who patches it, unless you bought managed service or IT management hours to do that work. Root access is the freedom and the job.
An app or a project, before a namespace
Compute has a smaller step than a namespace. Deploy an app from files, from a Cloud Storage Drive folder, or from the app library. Deploy a project when you want a container image, a worker, a cron job, or Kubernetes YAML. Apps and projects publish at a name such as your-app.broadbent.app, with HTTPS. CPU on that path is the Compute rate, £2.50 for a full month of one CPU, including the comparison printed on the Kubernetes page. An app or a project runs that one workload. It does not hand you the namespace.
Choose an app when you have files or a listed application and you want it on a broadbent.app name. Choose a project when the unit of deploy is an image or a small YAML workload, still as that one workload. Move to managed Kubernetes when you need several namespaces, a boundary around each, and a bill that covers every pod in them. The same 200 free hours are once per account across apps, projects and namespaces. Opening a namespace does not grant a second allowance.
When the namespace is the right object
Choose managed Kubernetes when all of these are true. You can name more than one process. You are willing to put a CPU and memory request on each pod. You want production and staging separated. You want a job to exist only while it runs. You want us to keep the nodes, the upgrades, the networking, the load balancer, the ingress and the certificate, and you want a kubectl login that cannot see the nodes or another customer.
The rates that follow from that choice are on the Kubernetes page and in the article. CPU is £12.50 for a 730-hour month, memory is £1.50 per GB, disk is 6p per GB, including VAT. Burst above the request is 125% up to double and 150% past double or when the pod has no request. Disk is not billed during the free hours. Afterwards the claim is billed while it exists. An empty credit balance suspends the namespace. KEDA is already installed. You add a ScaledObject or a ScaledJob. You do not install KEDA, and you cannot add a CustomResourceDefinition. Triggers can follow CPU, memory, a schedule, or a queue or database, from 0 to 20 replicas. The host must be a service in that namespace, the hosted MariaDB, or a public host.
If those sentences feel like a tax on a simple site, they are, and the site should stay on shared hosting or on one app. If those sentences match how you already deploy, the namespace is the product that was written for that.
A database beside any of these
Shared hosting can hold a small site database. A virtual server can run MariaDB or PostgreSQL that you install. Managed database hosting is the plan when you want the engine chosen at checkout, a dedicated IP or a shared virtual IP, daily or hourly backups, and an optional replica. Kubernetes does not include that database. A pod in the namespace can be a database, and then you are running it, backing it up, and paying for the pod and the disk. The hosted MariaDB is the other path, and it is the one a KEDA trigger is allowed to call by that name.
Do not put the only copy of production data on a container disk that disappears when the container is replaced. Persistent disk on Kubernetes survives the replacement and is billed after the free hours. A managed database survives because that is the product. Pick one of those on purpose.
A worked choice
A brochure and ten mailboxes: shared hosting, and the email plan if the mailboxes should be the email product rather than the hosting allowance. Add website maintenance if we should apply the updates. Add IT Micro or Small if the laptops need a help desk. No namespace.
A custom application with a web process, a worker and a nightly job, and a staging copy: managed Kubernetes, two namespaces, requests on each pod, the 200 free hours to prove it, then credit so the namespace is not suspended. MariaDB or PostgreSQL on database hosting if the data is the business. An app or a project if, after you sketch it, there is only one workload and the Compute CPU rate is the one you want.
A team that wants SSH, a package manager and a database on the same box: a virtual server, self-managed if you want root, managed if you do not. A Kubernetes cluster you administer yourself, node by node, is not this product. This product keeps the cluster. A dedicated server is the route when the whole machine must be yours.
A rack you already own: co-location in Colchester, not a namespace and not a VPS. Remote hands are separate. A Cisco ASA or Firepower appliance is the hardware firewall product when the rack needs that device.
What to do after you choose
Order the one product. Do not order all four and hope the bill explains the architecture. If you chose Kubernetes, claim the free hours once, put requests on the pods, and point the domain with an A record or a CNAME so the certificate can be issued. If you chose a server, decide managed or self-managed before the first patch Tuesday. If you chose shared hosting, put the site in Plesk and the mail on a plan you can name. The topic Kubernetes hosting is the landing page if the choice is already the namespace and you want the service described in one place.
Revisit the choice when the shape changes. A shared site that grows a queue and a worker has become the namespace case. A namespace that only ever runs one web pod has become the app case, at a lower CPU rate. Moving is allowed. Pretending the first order is still right, after the workload has changed, is how the bill and the outages diverge.
The free hours, counted properly
The 200 free hours are once per account. Each running pod, worker, job and cron job spends one of those hours for every hour it is running. One pod is about eight days. Three pods running together spend the allowance in a little under three days. A cron job spends hours only while it runs. Disk is not billed during the allowance. After it, managed Kubernetes is taken from the credit balance, and an empty balance suspends the namespace. An app or a project spends the same allowance. Deploying both does not create 400 hours.
That arithmetic is a reason to choose a virtual server instead, when the process must simply stay up for a month and you do not want a credit balance in the path. It is a reason to choose an app instead of a namespace, when there is one workload and the CPU rate you want is the Compute rate of £2.50 for a full month, rather than £12.50. It is a reason to stay on the namespace when the thing you are buying is the right to run several pods, scale them, and stop paying a job the moment it exits.
Who can see the namespace
The account owner sees the namespaces on the account. An admin, an operator or a 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 sees another customer's namespaces. The kubectl file from Connect to namespace reaches k8s.broadbent.host. It cannot list the cluster or the nodes, and it cannot open a shell. Privileged and host-level options are removed. Broadbent AI can draft one kubectl command from the names in the namespace you have open. Asking spends Broadbent AI credits. A viewer remains a viewer.
A self-managed virtual server is the opposite arrangement. You have root. You see the machine. You do not get a boundary that hides the node, because you are on the machine. Choose that when the team expects SSH. Choose the namespace when the team expects manifests and should not have the node.
A bill you can explain
Two web replicas at 0.5 CPU and 1 GB, plus a worker at the same request, is 1.5 CPU and 3 GB while they run. At the monthly rates that is £18.75 of CPU and £4.50 of memory, £23.25 before disk and before burst, including VAT, for a full 730-hour month. A 20 GB disk is £1.20 for that month after the free hours. Burst is only the amount above the request, at 125% up to double the request and 150% past it. A pod with no request is at 150% for what it uses. Replicas multiply pods. Staging is another namespace on the same bill. If you cannot explain that bill to the person who pays it, order the virtual server or the app, where the shape of the bill matches a machine or a single workload.
Shared hosting remains the cheapest mental model: a panel, a site, mail, and no request sizes. Dedicated and co-location remain the physical model: a machine or a rack in Colchester, backup power, A+B on those facilities, remote hands only when you ask and pay for them. Kubernetes is the namespace model. Use it when the bill above is the one you meant to buy.