Brewless Brewless Docs

Deployments

The deploy button

Put a "Deploy to Brewless" button in the README of a public Laravel repository, so anyone can run it in their own Scaleway project in one click.

On this page

A public Laravel repository on GitHub, Codeberg or GitLab can carry a button that deploys it to Brewless. Whoever clicks it gets the application in their own Scaleway project, on a test address of its own, without the command line.

Add the button to a README

Replace owner/name with your repository:

README.md
[![Deploy to Brewless](https://brewless.eu/img/deploy-to-brewless.svg)](https://brewless.eu/deploy?repository=github.com/owner/name)

For Codeberg or GitLab, put codeberg.org/owner/name or gitlab.com/group/name after repository=. On GitLab, a project in a subgroup works too.

The link opens a page on brewless.eu that asks for the address of your console, such as acme.brewless.eu, and continues there. In the console it opens Deploy a public repository, which you also find at /deploy in your console.

What happens when you deploy

  1. Brewless reads the repository at the newest commit of its default branch. It checks that composer.json requires laravel/framework, and reads brewless.yml if there is one. Nothing else of the repository is read.
  2. You choose a name, and Brewless makes the application, with a Scaleway project of its own when your key may make projects.
  3. The production environment is set up as brewless deploy would set it up from the file.
  4. The first release starts. The build job in your Scaleway project downloads the archive of that commit from the code host itself, so the code never passes through Brewless. The deployments page of the environment follows the release.

Deploying takes the right to manage applications, and a connected Scaleway project. The application counts towards the applications of your plan like any other.

The brewless.yml it uses

When the repository has a brewless.yml, its production environment is used, or its default-environment, or else its first environment. These are left out of it:

Left out Why
organisation and application They are the author's. Your organisation and the application you named take their place.
domains They are the author's domains. Add your own later under Domains.
kind and region The environment is a production environment in the default region.

A file that names services is refused: a service is pushed from a machine with brewless service:push, so deploy such a repository with the command line.

Without a brewless.yml, production gets a Serverless SQL Database, a queue in that database and the edge cache:

brewless.yml
environments:
  production:
    database: name-of-the-repository
    edge:
      cache: 1h

Afterwards

The application is yours like one you made yourself. Its next deploys come from your own copy of the code, with brewless deploy or from a pipeline: the button only makes the first release, and clicking it again makes another application. To follow the repository, fork or clone it and deploy from there.

Note

The button reads public repositories only. Brewless asks the code host's public API without a key, so a host that limits callers without a key may ask you to try again after a while.