Need a partner to implement or migrate?
This page is the honest version of “can you deploy into our cloud?” — yes, and here’s what it costs you. If you want a team to design the architecture and run the move, see Website migration.
What bring your own cloud actually means
Every platform page on this site has a line in it that says “…unless you have existing cloud commitments.” This is where that line lands.
Bring your own cloud means the front end of your web estate — the built site, the rendering layer, the image pipeline, the redirect map — is deployed into infrastructure your organisation already owns and already pays for. Your AWS, Azure, or GCP account. Your Akamai or Fastly contract. Your identity provider, your logging, your security review, your invoice.
What you’re buying from us in that model is the architecture and the delivery, not a hosting relationship. The stack is the same one we’d build on Vercel or Netlify: a modern framework, a headless CMS, a shared component library, a build that publishes without a developer in the loop. What changes is where it runs and who holds the pager.
This is a genuine option, not a consolation prize. It’s also the option that quietly costs the most to run badly, which is why the rest of this page is mostly about the trade.
What the setup looks like
The shape is the same everywhere, and it’s simpler than most teams expect:
- A build pipeline in whatever CI you already run — GitHub Actions, GitLab, Azure DevOps, Bitbucket. It builds the site on every merge and on a content webhook from the CMS.
- An origin for static output and for the rendered paths. Object storage for the built files; a container or serverless runtime for anything server-rendered.
- A CDN in front of it, doing cache rules, TLS, compression, and — on a replatform — the legacy redirect map.
- A promotion and rollback path, so a bad deploy is one command away from being undone. This is the part teams skip and then regret.
Frameworks are not the obstacle. Astro, Nuxt, and SvelteKit ship Node adapters that run anywhere a container runs. Next.js self-hosts through its standalone output as a plain Node server or Docker image, and the OpenNext adapter maps a Next.js build onto cloud primitives — Lambda functions for rendering and image optimisation, S3 for assets, CloudFront in front — for teams who want the serverless shape rather than a long-running server. OpenNext’s maintainers joined the Next.js ecosystem working group in 2026, which has made the gap between first-party and self-hosted behaviour narrower and better documented than it was two years ago. It is still an adapter, and adapters trail.
If you’re standardised on AWS
The common path is S3 for built assets, CloudFront for delivery, and Lambda or ECS/Fargate for rendering, wired up with the same infrastructure-as-code your platform team already uses. AWS Amplify exists as the managed shortcut and it’s a reasonable place to start for a single site — but on a multi-brand estate it tends to become a layer you’re working around rather than with, and most of our AWS clients end up on plain CloudFront plus their own pipeline for exactly that reason.
The real reason to pick AWS isn’t technical: it’s that the account, the roles, the network rules, and the spend commitment already exist, and adding a hosting vendor means a new security review, a new invoice, and a new supplier record for something your existing contract can already do.
If you’re a Microsoft shop
Azure covers the same ground with Static Web Apps for straightforward sites, App Service or Container Apps for rendered ones, and Azure Front Door Standard or Premium as the CDN and WAF layer. If you’re on Front Door classic, note it retires on 31 March 2027 and no longer accepts new profiles or domains — a replatform is a sensible moment to move to Standard or Premium rather than doing the migration twice.
The pull here is usually organisational rather than technical. If identity runs through Entra ID, if the data platform is in Azure, and if procurement’s default answer to a new vendor is “put it in Azure,” the front end joining the rest of the estate removes more friction than any platform feature adds.
If your CDN contract is already signed
Akamai and Fastly contracts are typically negotiated at a scale that makes the marginal cost of adding one more property close to nothing — and they usually come with the WAF, bot management, and support relationship your security team already accepted. In that case the CDN choice is made and the only open question is the origin behind it. We’ve also fronted estates hosted elsewhere with the client’s existing CDN, which is a perfectly sane middle path.
Cloudflare is worth a separate look here rather than being treated as “the CDN”: if it’s already your DNS and WAF, hosting the front end on the same network is closer to a platform decision than a delivery one — see Cloudflare.
What you give up versus Vercel
This is the part the vendor-neutral pitch usually skips, so here it is plainly. Moving into your own cloud costs you four things:
- Preview deployments as a review workflow. A URL per branch, opened by a marketer or a legal reviewer, is the single biggest velocity feature the platforms sell. You can rebuild it — ephemeral environments per pull request are a solved problem — but it’s now a system your team builds, maintains, and pays for in build minutes and storage, rather than a checkbox.
- First-party framework behaviour. ISR, image optimisation, and middleware are exactly where adapters and first-party support diverge, and they’re exactly what a large content estate leans on. Expect to test them deliberately on each framework upgrade instead of assuming they work.
- The edge network as an operating concern. Cache keys, invalidation on publish, stale-while-revalidate policy, origin shielding, certificate rotation. None of it is hard. All of it is now yours, and it’s the category of work that’s invisible until a campaign launches behind a stale cache.
- Platform maintenance and on-call. Runtime versions, dependency and base-image patching, capacity, and someone to answer at 2am. If your organisation already runs production infrastructure, this is marginal. If it doesn’t, this is the whole decision.
The honest summary: you trade a monthly invoice for engineering ownership. That’s a good trade when you have the ownership already and a bad one when you’re hoping to acquire it as a side effect of a website project.
When it’s the right call
| Bring your own cloud when | Use a platform when |
|---|---|
 Data residency or sovereignty rules require workloads inside your own tenancy |  Compliance is satisfied by a vendor's certifications and regional deployment options |
| Procurement treats a new hosting vendor as a months-long exercise, and your cloud account is already approved | Adding a vendor is routine and the security review is not the bottleneck |
| You hold committed cloud spend or a negotiated CDN contract that the estate can be absorbed into | Your traffic sits comfortably inside a platform's included allowances |
| Traffic is high and steady enough that metered bandwidth and image optimisation dominate the bill | Traffic is spiky and modest, where usage-based pricing is the cheaper shape |
| A platform team already operates CDN, compute, and CI — and wants to keep doing it | Nobody owns the platform work, and marketing velocity is the point of the project |
The cost question, honestly
Owning the infrastructure is cheaper per gigabyte and rarely cheaper overall on day one. Three lines actually move:
Delivery. This is where the saving is real. Metered bandwidth and per-image transformation charges on a platform scale linearly with traffic; a committed CDN contract or a network that doesn’t meter egress does not. On a content-heavy, media-heavy estate at sustained traffic, this line alone can justify the whole move — and it’s the same arithmetic that makes Cloudflare attractive without leaving the platform model.
Compute. Roughly a wash. Serverless rendering in your own account costs what serverless rendering costs; the platform margin you stop paying is offset by the reserved headroom you now provision yourself.
People. The line nobody budgets. Pipeline, CDN configuration, upgrades, and incident response are a standing commitment measured in engineer-days per month, not a one-off setup cost. Price it at your loaded rate and compare that number to the platform invoice before you decide. Where organisations get burned is not the migration — it’s month fourteen, when the person who built the pipeline has moved on.
If you want the full evaluation side by side rather than the commercial one, self-hosting vs Vercel and Netlify works through the same decision from the buy side.
The Bejamas take
We deploy into client clouds regularly and we don’t treat it as a downgrade. The stack, the CMS, the component library, and the publishing workflow are identical; the difference is the operating model behind them, and for organisations with real residency requirements or serious committed spend, the operating model is the point.
What we push back on is choosing it for the wrong reason. “We’ll save on hosting” is usually false once the people line is priced. “Our data can’t leave our tenancy” and “procurement will not approve another vendor this year” are both true reasons, and they’re the ones we hear most.
In an audit we model the estate across both paths — your cloud and the platforms — with your actual traffic, your compliance constraints, and your team’s real capacity, and we recommend the one the numbers support. We’ll also tell you when the answer is Vercel, because for a lot of Next.js estates it still is.