# 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.


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](/running/domains#the-test-address) of its own, without the command line.

## Add the button to a README

Replace `owner/name` with your repository:

```markdown 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:

```yaml 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](/deployments/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.