# A Scaleway project per Laravel app, or a shared one

Why Brewless gives every Laravel application its own Scaleway project, what that changes for keys, invoices and mail, and when to share one instead.

## In short

- A Scaleway project is the boundary for access keys, billing lines, Private Networks and mail sending, so one project per application keeps those apart.
- With an organisation-wide key that holds IAMManager, Brewless makes a Scaleway project for every application you add, or lets it share the project of another application.
- Applications in one project can share a database, a cache, a Private Network and a mail domain; applications in different projects cannot.
- The project an application runs in is chosen when you add it and does not change later.
- A key limited to one project still works, but every application then runs in that project and you set some database and bucket keys yourself.

On Scaleway, almost everything you make lives in a *project*: containers, databases, buckets, queues, secrets, Private Networks. Most teams start with the default project and put everything in it. That works until the second or third application, when the invoice turns into one long list and an access key for one app quietly reaches the buckets of another.

Since this week, [Brewless](/) gives every Laravel application a Scaleway project of its own, unless you ask it to share one. This post explains what a project is a boundary for, what Brewless makes in it, and when sharing is the better choice.

## Why does each Laravel app get its own Scaleway project?

Because the project is where Scaleway draws its lines: rights are granted per project, the bill is split per project, and a Private Network or a mail domain stays inside one. One project per application keeps the access of each app to its own resources and puts its costs on its own lines of your invoice.

It is the same idea as a separate AWS account per workload, at a much smaller scale: no new login, no new payment method, just a second box inside the Scaleway organisation you already have.

## What a project separates

| Boundary | What it means for your Laravel app |
| --- | --- |
| Access | An identity that may read "the buckets of this project" reaches every bucket in it. Scaleway grants this per project, not per bucket |
| Billing | Scaleway bills per resource, with the project it stood in. A project per app is a cost line per app |
| Networking | A Private Network does not reach another project, so a database on one cannot be used from another project |
| Serverless SQL | The identity that signs in to a Serverless SQL Database may use the databases of its own project |
| Transactional Email | The offer, the sending limit and the reputation of a domain belong to one project |
| Quota | An organisation has 25 projects unless Scaleway support raised that |

Put two applications in one project and they share all of the rows above, whether you meant them to or not.

## What Brewless makes in the project

When you add an application, Brewless makes its project straight away, named after the application or after a name you give, such as `websites`. Setting up an environment then puts everything of that environment there: the registry, the web, release and worker containers, the database, the queue, the bucket and the variables in Secret Manager. See [Applications and environments](https://docs.brewless.eu/applications/applications-and-environments).

Every environment also gets identities of its own, each allowed only what it needs:

- **The database.** For a Serverless SQL Database, an identity that may use the databases of this project and nothing else.
- **The bucket.** An identity that may read the buckets of this project and read, write and remove the objects in them, but may not make, change or remove a bucket.
- **The queue.** A key that may send and receive, and may not make or remove queues.
- **Mail.** With Scaleway Transactional Email, an identity that may only send.

The keys go into the environment's own Secret Manager; Brewless keeps their names, never their values. Because those rights stop at the edge of the project, the bucket key of your shop cannot read the uploads of your blog.

> [!NOTE]
> Scaleway does not keep project names unique: a second project with the same name is simply a second project. Brewless finds its own by a line in the description, `Managed by Brewless · application …`, so a project of yours that happens to share the name is left alone.

## The key it takes

Making projects and identities takes rights at the level of the organisation. The API key you connect on the **Providers** page then has a policy with two rules:

1. **Resource management**, scope **All projects**: the product permission sets, such as `ContainersFullAccess`, `ContainerRegistryFullAccess` and `ObjectStorageFullAccess`. The full list, with what is required and what is optional, is in [Scaleway permissions](https://docs.brewless.eu/reference/scaleway-permissions).
2. **Organization management**: `IAMManager`, which includes `ProjectManager`. Add `BillingReadOnly` if you want the Costs page to show what Scaleway charged.

**Check rights** next to a connected project asks Scaleway again, with read-only calls, what the key may do, and shows a tick or a cross per right, with the permission set that grants it.

> [!WARNING]
> `IAMManager` is a wide right. Scaleway warns that whoever holds a key with it could give that key any other right in the organisation. Treat that key like the keys to the building, and never connect your own login or an owner key.

### If you would rather not

You do not have to. Leave the organization management rule out and choose **Specific projects** with one project instead of **All projects**. Every application then runs in that one project, as before. What Brewless cannot make without `IAMManager` is named for you to set: `DB_USERNAME` and `DB_PASSWORD` for a Serverless SQL Database, and `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` for the bucket. Push them with `brewless env:push`.

For your Brewless plan it makes no difference in the other direction either: a key on the whole Scaleway organisation counts as one cloud account, however many applications get a project of their own with it. See [Billing](https://docs.brewless.eu/organisation/billing).

## When to share a project

A project of its own is the default, but not always the right answer. Some things only work inside one project:

- **One database for several apps.** A database in the project of another application is refused, because its Private Network and the identities of a Serverless SQL Database do not reach across. Linking still gives each environment a login of its own.
- **A shared cache or Private Network.** Same reason.
- **One mail domain.** A domain is at Transactional Email in one project, so two applications that each have a project cannot send from the same domain.

The typical case is a handful of small marketing sites or client websites that run happily on one database. Give the first one a project named `websites`, and let the others share it. Scaleway then bills them together, which is what they are.

You choose when you add the application, in the console or with `brewless init`:

```bash
brewless init --project-name=websites
```

and for the next application that should sit next to it:

```bash
brewless init --share-project=agency-site
```

`--share-project=` takes the slug of an application that has a project of its own. Without a terminal and without either option, the application gets a project of its own, named after it. See [brewless init](https://docs.brewless.eu/cli/commands#init).

> [!TIP]
> Decide before you add the application. The project an application runs in holds for all its environments and does not change later.

## What you see on the invoice

The main reason to bother is the bill. On the **Costs** page, Brewless reads back what Scaleway and bunny.net charged your own accounts and splits it per application, environment, project, kind of resource and product group. Scaleway gives a line per resource per month with the project it stood in, so with a project per application those lines land on the right application, including the lines that read as what Scaleway sells rather than as something you made, such as CPU consumption in a region.

An application's own page shows the same figures for that application alone. It only adds up to what the application really used when it has a project of its own. An application from before this change, or one that shares a project, shows what Brewless could trace to its own resources and says so; the rest stands with the project. See [Costs](https://docs.brewless.eu/organisation/costs).

The same applies in the Scaleway console itself: open the project and you see one application, not everything you ever deployed.

## Mail gets its own reputation

This one is easy to miss. With Scaleway Transactional Email, an offer, a sending limit and the reputation of a domain belong to the project. An application with a project of its own starts there with its own: a new project can send 10,000 mails a month at first, and Scaleway raises that after a support request. A newsletter tool that lands in spam folders no longer drags down the password resets of your SaaS. The [Transactional Email comparison](/blog/scaleway-transactional-email) has the rest of that picture.

## What about applications you already have?

They stay where they are. An application keeps the project it was made in, and nothing is moved for you. New applications get the new behaviour as soon as the key may make projects.

## Leaving

Every project Brewless makes is a project in your own Scaleway organisation, billed to you by Scaleway. If you stop using Brewless, the projects and everything in them stay where they are, and the split you had on your invoice stays with them. [Laravel hosting without lock-in](/blog/laravel-hosting-without-lock-in) covers the rest of what happens when you leave.

## Summary

1. A Scaleway project is the boundary for rights, billing lines, Private Networks and mail.
2. With `IAMManager` and **All projects**, Brewless makes a project per application, with identities per environment that stop at its edge.
3. Share a project when applications need one database, cache, network or mail domain.
4. Choose when you add the application; it does not change later.
5. Without `IAMManager`, everything runs in one project and you set a few keys yourself.

[Connecting providers](https://docs.brewless.eu/applications/providers) has the exact steps for the key.

## Frequently asked questions

### Why give every Laravel application its own Scaleway project?

Scaleway grants many rights per project and bills per project. With a project of its own, an application's bucket and database identities reach only its own resources, its costs add up per application on your invoice, and its mail sending limit and domain reputation are its own.

### When should two applications share a Scaleway project?

When they need to share something that does not cross a project, such as one database, a cache, a Private Network or a mail domain. A group of small websites on one database is the typical case. Scaleway then bills them together.

### Which Scaleway rights does Brewless need to make projects?

A policy with two rules. The product permission sets under resource management with the scope All projects, and IAMManager under organization management. IAMManager includes ProjectManager and lets Brewless make identities per environment.

### Is IAMManager safe to hand out?

It is a wide right. Scaleway warns that a key with it could give itself any other right in the organisation. If you would rather not, limit the key to one specific project and leave the organization management rule out; every application then runs in that one project.

### How many Scaleway projects can an organisation have?

Scaleway allows 25 projects per organisation unless its support raised that. When they are in use, Brewless says so when it tries to make one, and sharing the project of another application is the way to add more applications.

Source: https://brewless.eu/blog/scaleway-project-per-laravel-app