A Scaleway project per Laravel app, or a shared one

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#

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.

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

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:

brewless init --project-name=websites

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

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.

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.

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 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 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 has the exact steps for the key.