Laravel hosting without lock-in: what happens when you leave

Every hosting platform says you can leave. The useful question is what you would have to move, rebuild or rewrite when you do. For a lot of Laravel hosting the honest answer is: the app, the database, the files, the DNS and the secrets, because all of them live in the platform's account, not yours.

This post looks at what lock-in means for Laravel hosting, how owning your cloud accounts changes it, and what exactly stops and what keeps running when you leave Brewless.

What is lock-in in Laravel hosting?#

Lock-in is the cost of leaving: the work, the risk and the downtime of moving your app away from the platform that runs it. It is high when the platform owns the infrastructure, the data or the contract, because leaving then means rebuilding all of it elsewhere. It is low when those are yours and the platform only operates them.

There are a few kinds of lock-in, and they are easy to mix up:

A platform can be fine on one row and bad on another. A tool that deploys into your own AWS account, for example, takes care of the first three rows, but leaves you with a US provider.

Owning your cloud accounts#

With Brewless, you open the Scaleway project and the bunny.net account yourself, and hand Brewless an API key limited to that one project. Everything Brewless sets up goes into those accounts:

Three choices keep the right-hand column small:

• Visitor traffic never passes through Brewless. It goes from bunny.net straight to your containers.
• Builds run in your own Scaleway project, as a job there. Your code goes from your machine into your project and never passes through Brewless.
• Secrets stay in your own Secret Manager. Brewless keeps the names and revisions of your variables, never their values.

That also covers the data and contract rows: the database and the files are in your project, and Scaleway and bunny.net bill you directly. Brewless takes no percentage of the cloud bill.

Export: get the configuration out as files#

The configuration row is covered by the export. It writes everything Brewless knows about an environment as files:

brewless export production

No value of a secret is in it. Exporting changes nothing, so you can run it any time, also just to see what Brewless holds. The console has the same under Resources.

Tip

Run an export once early on, before you need it. Reading resources.json is the quickest way to see exactly what lives in your accounts.

The Terraform file#

main.tf has, for every resource, a block that imports it and a block that describes it. With your own provider keys:

export SCW_ACCESS_KEY=... SCW_SECRET_KEY=... BUNNYNET_API_KEY=...
terraform init
terraform plan

The plan imports every resource and wants to change nothing. Some things are left out on purpose, such as the image and variables of a container, so a later plan does not undo a release, and the settings of a bunny.net pull zone, which are taken over as they are. Leaving Brewless lists each of them.

Detach: what stops and what keeps running#

Detaching ends what Brewless does for an environment:

brewless detach production

A last export is made first, and nothing at your providers is touched.

The environment, its releases and the audit trail stay in Brewless as a record of what happened. Detaching waits for work that is under way: while a deploy runs, it is refused.

Note

Your provider keys belong to your organisation, not to one environment. When Brewless manages nothing else for you, disconnect them under Providers, and delete the key at Scaleway and bunny.net to end its access for good.

Deploying without Brewless#

The code row matters too. Your Laravel app needs the brewless/laravel package to take release commands, the queue and the schedule in its containers. That package is open source, as are the command line client and the base image your releases are built on.

After you leave, a release is three plain calls to your provider, described in the README.md of the export:

1. Build an image and push it to your registry.
2. Give the release container that image and call its release route with your ops secret. That runs your release commands, such as migrations.
3. Give the web and worker containers the same image.

You can script that in any pipeline, or keep using the Terraform from the export to manage the resources around it.

Coming back#

Leaving is not one-way. The resources are still yours and still running, so you can adopt them again on the Resources page of the environment. See Applications and environments.

Summary#

1. Lock-in is the cost of leaving: infrastructure, data, contract, configuration and code.
2. With your own Scaleway and bunny.net accounts, the infrastructure, data and contract are yours from the start.
3. brewless export gets the configuration out as files, with Terraform that imports every resource.
4. brewless detach stops deploys, rollbacks and scaling through Brewless; your app, data, domains and secrets keep running.
5. A release without Brewless is three calls to your provider, with open-source tools.

Why owning your accounts also matters for EU sovereignty is in How to host a Laravel app EU-sovereign.