The alternatives, side by side
Every hosting decision is really a choice between a handful of options. Here's what each one actually costs you, what it's genuinely good at, and where it — not us — is the right call.
What you're actually choosing between
Four real ways to host something, described plainly — including where each one beats us.
Rolling it yourself on a cloud account
Provisioning compute, storage, a CDN, DNS, and TLS directly on a major cloud provider’s console or CLI, and operating all of it yourself.
- Genuinely better at
- Full, granular control over every setting, and same-day access to the provider’s entire feature surface — nothing sits behind an abstraction layer.
- Costs you
- Provisioning, DNS, TLS renewal, backups, patch cadence, monitoring, and the on-call rotation when something breaks are all now a job someone on your team owns.
Pick this instead ifPick this instead if your team already has that operations skill in-house and keeping it there is itself a goal, not just a means to an end.
The same infrastructure category, run for you: TLS, DNS, backups, patching, and monitoring are included on every plan, and a human answers when it breaks — the operations job moves off your plate without moving your stack onto anything proprietary.
A self-serve deploy platform
Push-to-deploy hosting billed by usage — request volume, compute time, or bandwidth — with a generous free tier and instant provisioning.
- Genuinely better at
- Nothing to sign up for beyond a git push — genuinely the fastest way to get a prototype or a low-traffic side project live for free.
- Costs you
- The bill is a function of traffic you don’t fully control, and it can move a long way between a quiet month and a launch-day spike.
Pick this instead ifPick this instead if the project is a prototype, a weekend build, or something you’re genuinely happy to watch the meter on.
One flat monthly rate regardless of how traffic moves — the same instant-deploy convenience, minus the metered bill and the guesswork about what a launch-day spike will cost.
A traditional web host or control-panel plan
A shared or VPS plan through a hosting-panel dashboard, usually sold on a fixed monthly or annual price.
- Genuinely better at
- Familiar and dashboard-driven, often at the cheapest sticker price you’ll find for a small brochure site.
- Costs you
- Deploys usually mean an FTP upload or a dashboard click, not a pipeline — and the plan is priced for a site that stays still, not one that keeps changing.
Pick this instead ifPick this instead if the site is genuinely finished — a brochure that won’t change again — and clicking through a console yourself doesn’t bother you.
The same flat, predictable pricing, but deploys come from a push to your repo instead of a dashboard upload, and a real person — not a shared support queue — answers when something needs attention.
An agency or freelancer on retainer
Paying a development shop or a contractor a standing monthly fee to build the first version and handle changes as they come up.
- Genuinely better at
- A real person who understands the whole product, not just the hosting — the right call when the work is genuinely bespoke design or product strategy.
- Costs you
- Changes queue behind whatever else that person or shop is billing hours to this week, and the retainer is priced for their time, not for the size of any one change.
Pick this instead ifPick this instead if what you actually need is design and product decisions, not infrastructure — that’s different work, and a good agency earns a retainer for it.
CustomLabs builds the first version the same way an agency would — but the loop keeps shipping the small stuff after launch: brief a change in plain language, an agent opens a pull request, the same pipeline ships the merge, no retainer required for routine changes.
Dimension by dimension
The same seven questions, answered for every option — including us.
| Dimension | Rolling it yourself on a cloud account | A self-serve deploy platform | A traditional web host or control-panel plan | An agency or freelancer on retainer | With CustomHosted |
|---|---|---|---|---|---|
| Getting live the first time | You provision every piece yourself — compute, storage, DNS, TLS — before anything is reachable. | A git push and it’s live in seconds — no infrastructure to provision at all. | A dashboard signup and an upload — plan-dependent, but usually same-day. | Live whenever the build is finished — days or months, depending on scope. | Static sites live in minutes; most other stacks are live within days of the brief — provisioned for you, not by you. |
| Who owns TLS, DNS, backups and patching | You do — issuing certificates, managing records, scripting snapshots, and watching for CVEs yourself. | TLS and DNS are usually handled by the platform; backups and OS patching aren’t its job, since there’s no server to patch. | Usually bundled, at whatever quality the plan happens to include — rarely something you can inspect or improve. | Whoever they choose to host it with — an extra layer between you and how any of this actually works. | All of it, included on every plan: certificates renew themselves, DNS is managed end to end, backups run nightly, and patches ship on a schedule — nothing to script or remember. |
| Shipping the next change | Whoever wrote the original setup has to be available, or someone has to relearn it first. | Fast for the app code itself, but a platform-level change to how the whole thing is provisioned is a bigger lift. | Often a manual re-upload — no pipeline, no review, no record of what changed. | Queued behind whatever else the agency or contractor is billing hours to this week. | Brief it in plain language — a CodeHerder agent opens a pull request against the real repo, a human reviews it, and the same pipeline that runs your hosting ships the merge. CustomLabs builds it, CodeHerder iterates it, CustomHosted runs it — one continuous loop, not three vendors to coordinate. |
| What the bill does when traffic moves | Scales with granular, itemised pricing across every service you provisioned — accurate, but real work to predict. | Scales directly with usage — a launch-day spike can turn a free-tier project into a real invoice overnight. | Usually flat until you exceed a resource cap, then either throttled or a forced upgrade. | Unaffected by traffic, but hosting is billed separately by whoever’s hosting it. | Flat and unaffected by a traffic spike — one posted rate, whether it’s a quiet month or launch day. |
| Who answers when it breaks | Whoever’s on call on your team, at whatever hour it happens. | A support queue, usually tiered by plan, for a platform-wide issue. | A shared support queue, sized for a very high ticket volume. | Whoever’s available at the agency, during their hours — if the retainer covers incidents at all. | A human from the team that runs your stack, through the same quote channel — routine questions in business hours, priority handling on outages. |
| Outgrowing the starter shape | You resize and re-architect it yourself, the same way you built it. | Usually a plan upgrade, until the app needs something the platform’s abstraction doesn’t expose. | A plan upgrade or a migration to a different product line entirely. | A new scoping conversation and, often, a new quote. | Move up a tier on the same instance, or add a database or an add-on — no rebuild or redeploy required beyond the usual push. |
| Getting your stuff out | Already yours — the effort was standing it up, not leaving. | Straightforward for the app code; platform-specific configuration sometimes doesn’t travel. | Often a manual export from a proprietary dashboard. | Depends entirely on what they hand over, and whether it’s documented. | Everything is defined as code and fully portable — a free, documented handover any time, no untangling required. |
Where we're the wrong choice
A comparison that never says this isn't worth trusting.
- You need round-the-clock, sub-minute incident response with dedicated on-call staff — support here runs in business hours, with priority handling on outages, not a 24/7 operations centre.
- You need infrastructure and code changes merged with no human review step at all — the loop’s plain-language brief still goes through a reviewed pull request before anything ships, by design.
- Your traffic is so rare or bursty that a usage-billed free tier would cost less than any flat monthly rate — that’s a real trade-off in the self-serve platform’s favour, not ours.
- Deepening your team’s own in-house operations skill — not just keeping a site running — is the actual goal — handing that work to us doesn’t build the muscle you’re after.
Questions this page raises
The follow-ups that come up once someone's actually weighing the options.
01Is this just cloud hosting with a markup?
No — the infrastructure is the cheap part. What’s being paid for is the managed layer around it: TLS, DNS, backups, patching, monitoring, and a human who answers, all included instead of assembled by hand.
02How is this different from a self-serve deploy platform?
A self-serve platform bills by usage and hands you a support queue. This is a flat monthly rate regardless of traffic, and a human from the team that runs your stack answers when something comes up.
03We already have a host — can we just use the CodeHerder loop?
The loop is built around hosting the app here, so its pull requests deploy through the same pipeline that runs the site. Migrating first is usually the simpler path — see the migration guide for what a cutover looks like.
04Do you compete with agencies and freelancers?
No — CustomLabs builds the first version the same way an agency would. The difference shows up after launch: the loop ships the steady stream of small changes without a standing retainer for routine work.
05Why not just hire a developer?
A hire is the right call for deep, ongoing product work. For the routine changes — a new page, a copy fix, a small feature — briefing the loop in plain language is faster than opening a req.
Still weighing it up?
- Which do I need?
Not sure which hosting shape fits? Answer a few questions and get a recommendation.
- Pricing
The flat rate card behind every "what the bill does when traffic moves" row above.
- The Loop
Build, iterate, run — the loop behind the "shipping the next change" row, in full.
- The hours ledger
Weighing rolling it yourself against this page's alternatives? Put your own hours and rate in and see the real number.
- Performance
The measured page weight and request count behind the "fast on the edge" row above.
- Scaling
The ladder and the move, minute by minute, behind the "outgrowing the starter shape" row above.
Made your choice?
Describe the workload and get one fixed monthly rate in writing, within a business day.