Merge branch 'master' into v3

# Conflicts:
#	docs/runtimes.mdx
#	docs/setup.mdx
#	layers.json

Author: mnapoli

.github/workflows/website.yml

@@ -11,12 +11,16 @@ env:
 jobs:
 
     deploy:
-        runs-on: ubuntu-22.04
+        runs-on: ubuntu-latest
+        concurrency: deploy-prod # Avoid deploying concurrently
         permissions:
             contents: read
         defaults:
             run:
                 working-directory: ./website
+        environment:
+            name: prod
+            url: https://bref.sh
         steps:
             -   uses: actions/checkout@v4
                 with:

bref

@@ -32,8 +32,7 @@ switch ($argv[1] ?? '') {
         error('Since Bref 2.0, the "bref local" command has been moved. Read https://bref.sh/docs/local-development/event-driven-functions\n');
     case 'dashboard':
         cliWarning();
-        echo "The Bref Dashboard is now available as a desktop application.\n\n";
-        echo "Check out https://dashboard.bref.sh/\n";
+        echo "Check out Bref Cloud: https://bref.sh/cloud\n";
         exit(1);
     case '':
         help();

docs/cloud-deploy.mdx

@@ -96,6 +96,10 @@ jobs:
         runs-on: ubuntu-latest
         timeout-minutes: 15
         concurrency: deploy-prod # Avoid deploying concurrently
+        environment:
+            name: prod
+            # Optionally set a URL for the environment
+            # url: https://example.com
         steps:
             -   uses: actions/checkout@v4
 

docs/cloud-security.mdx

@@ -24,6 +24,8 @@ To use the AWS API, Bref Cloud needs **AWS credentials** that give access to the
 
 Bref Cloud does not use long-lived AWS credentials (aka AWS access keys). Instead, it follows standard AWS best practices and uses IAM roles with [temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-workloads-use-roles).
 
+Note that all of this happens automatically and is easy to set up in the Bref Cloud web interface.
+
 ## How it works
 
 ```mermaid

docs/cloud/logs.png

@@ -1,3 +1,5 @@
+import { Tab, Tabs } from 'nextra/components';
+
 # CLI commands
 
 We can run CLI commands and scripts on AWS Lambda by deploying a "console" function with `serverless.yml`.
@@ -13,15 +15,33 @@ The function uses the [Console runtime](../runtimes/console.mdx).
 
 To execute the script on Lambda, run the command below:
 
-```bash
-serverless bref:cli
-```
+<Tabs items={['Serverless CLI', 'Bref Cloud']}>
+    <Tab>
+        ```bash
+        serverless bref:cli
+        ```
+    </Tab>
+    <Tab>
+        ```bash
+        bref command
+        ```
+    </Tab>
+</Tabs>
 
 We can also pass arguments to the script:
 
-```bash
-serverless bref:cli --args="extra command line arguments and options"
-```
+<Tabs items={['Serverless CLI', 'Bref Cloud']}>
+    <Tab>
+        ```bash
+        serverless bref:cli --args="extra command line arguments and options"
+        ```
+    </Tab>
+    <Tab>
+        ```bash
+        bref command "extra command line arguments and options"
+        ```
+    </Tab>
+</Tabs>
 
 Our script will be invoked inside AWS Lambda and the result will be printed to the console.
 

docs/default/cli-commands.mdx

@@ -1,4 +1,4 @@
-import { Cards, Card } from 'nextra/components';
+import { Cards, Card, Tabs, Tab } from 'nextra/components';
 // Path relative to the copy in the `website/` folder
 import { LaravelIcon } from '../../../components/icons/LaravelIcon';
 import { SymfonyIcon } from '../../../components/icons/SymfonyIcon';
@@ -70,9 +70,18 @@ plugins:
 
 To deploy, run:
 
-```bash
-serverless deploy
-```
+<Tabs items={['Serverless CLI', 'Bref Cloud']}>
+    <Tab>
+        ```bash
+        serverless deploy
+        ```
+    </Tab>
+    <Tab>
+        ```bash
+        bref deploy
+        ```
+    </Tab>
+</Tabs>
 
 Once the command finishes, it should print a URL like this one:
 

docs/default/getting-started.mdx

@@ -1,4 +1,4 @@
-import { Callout } from 'nextra/components';
+import { Callout, Tab, Tabs } from 'nextra/components';
 
 # Deployment
 
@@ -10,16 +10,21 @@ Bref can also work with any other deployment tool: Terraform, CloudFormation, SA
 
 To deploy to AWS an application configured with `serverless.yml`, run:
 
-```bash
-serverless deploy
-```
+<Tabs items={['Serverless CLI', 'Bref Cloud']}>
+    <Tab>
+        ```bash
+        serverless deploy
+        ```
+    </Tab>
+    <Tab>
+        ```bash
+        bref deploy
+        ```
+    </Tab>
+</Tabs>
 
 A `.serverless/` directory will be created. You can add it to `.gitignore`.
 
-<Callout>
-    Want to get an overview of your deployed application? Check out the [Bref Dashboard](https://dashboard.bref.sh/?ref=bref).
-</Callout>
-
 ## Deploying for production
 
 In the previous step, we deployed the project installed on your machine. This is probably a *development version*.
@@ -44,25 +49,54 @@ Now is also the best time to configure your project for production, as well as b
 
 Once your project is ready, you can deploy via the following command:
 
-```bash
-serverless deploy
-```
+<Tabs items={['Serverless CLI', 'Bref Cloud']}>
+    <Tab>
+        ```bash
+        serverless deploy
+        ```
+    </Tab>
+    <Tab>
+        ```bash
+        bref deploy
+        ```
+    </Tab>
+</Tabs>
+
+## Environments
+
+We can deploy the same application multiple times in completely separated environments (also called "stages" by the Serverless CLI).
+
+<Tabs items={['Serverless CLI', 'Bref Cloud']}>
+    <Tab>
+        ```bash
+        serverless deploy --stage=prod
+        ```
+    </Tab>
+    <Tab>
+        ```bash
+        bref deploy --env=prod
+
+        # or
+        bref deploy -e prod
+        ```
+    </Tab>
+</Tabs>
+
+The default environment is `dev`. The example above deploys a `prod` environment.
+
+Each environment is a separate CloudFormation stack, with completely separate AWS resources (Lambda functions, logs, permissions, etc.). All AWS resources are prefixed with the `service` and environment name (for example `myapp-dev-api`), which avoids any collision between environments.
+
+It is possible to deploy different environments in different AWS accounts (to lock down permissions), and to deploy one environment per git branch, pull request, or even developer in the team.
 
-## Stages
-
-Serverless Framework has a concept of "stages", another name for "environments". We can deploy the same application multiple times in completely separated environments:
-
-```bash
-serverless deploy --stage=prod
-```
+## Automating deployments
 
-The default stage is `dev`. The example above deploys a `prod` stage.
+### Bref Cloud
 
-Each stage is a separate CloudFormation stack, with completely separate AWS resources (Lambda functions, logs, permissions, etc.). All AWS resources are prefixed with the `service` and stage name (for example `myapp-dev-api`), which avoids any collision between stages.
+If you are using [Bref Cloud](https://bref.sh/cloud), you can easily set up automatic deployments from CI/CD tools.
 
-It is possible to deploy different stages in different AWS accounts (to lock down permissions), and to deploy one stage per git branch, pull request, or even developer in the team.
+Read the [documentation on deploying with Bref Cloud](./cloud-deploy.mdx) for more information.
 
-## Automating deployments
+### Serverless CLI
 
 If you are using GitHub Actions, Gitlab CI, CircleCI, or any tool of the sort you will want to automate the deployment to something like this:
 
@@ -96,40 +130,58 @@ provider:
 
 <Callout>
     If you are a first time user, using the `us-east-1` region (the default region) is recommended for the first projects. It simplifies commands and avoids a lot of mistakes when discovering AWS.
-
-    I mean really… I can't count how many times a command failed or an AWS page looked empty because I was in the wrong region.
 </Callout>
 
 ## Deletion
 
-To delete the whole application you can run:
+You can delete a deployed environment using the `remove` command.
 
-```bash
-serverless remove
-```
+<Tabs items={['Serverless CLI', 'Bref Cloud']}>
+    <Tab>
+        ```bash
+        serverless remove
 
-Note that this command, like `serverless deploy`, is for a specific stage. If you want to delete all stages you will have to run the command once per stage.
+        # or remove a specific environment
+        serverless remove --stage=prod
+        ```
+
+        Note that because of the way Serverless Framework works, you will need to delete the contents of AWS S3 buckets manually before running this command.
+    </Tab>
+    <Tab>
+        ```bash
+        bref remove
+
+        # or remove a specific environment
+        bref remove --env=prod
+        ```
+
+        Bref Cloud will automatically delete the contents of AWS S3 buckets.
+    </Tab>
+</Tabs>
+
+**Deleting an environment destroys the AWS resources that were created for that environment.**
+
+If you want to delete all environments of an application, you can do so in the [Bref Cloud dashboard](https://bref.cloud). If you don't use Bref Cloud, you will need to delete each environment one by one.
 
 ## How it works
 
 ### CloudFormation stacks
 
-The `serverless deploy` command will deploy everything via a **[CloudFormation](https://aws.amazon.com/cloudformation/) stack**. A "stack" is nothing more than a bunch of things that compose an application:
+Under the hood, Bref will deploy everything to AWS as a **[CloudFormation](https://aws.amazon.com/cloudformation/) stack**. A "stack" is nothing more than a bunch of things that compose an application:
 
-- lambda functions
+- Lambda functions
+- HTTP endpoints
 - S3 buckets
 - databases
 - etc.
 
 Stacks make it easy to group those resources together: the whole stack is updated at once on deployments, and if you delete the stack all the resources inside are deleted together too. Clean and simple.
 
-All of this is great except CloudFormation configuration is complex. This is where Serverless Framework helps.
-
 ### Zero-downtime deployments
 
 CloudFormation deploys using the [blue/green deployment strategy](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/bluegreen-deployments.html).
 
-This means that when you deploy, a new version of your code is deployed alongside the old one. Once the new version is ready, the traffic switches to the new version. If the deployment fails at any point, the traffic stays on the old version.
+This means that when you deploy, a new version of your code is deployed alongside the old one. Once the new version is ready, the traffic switches to the new version. If the deployment fails at any point, the traffic stays on the old version and the deployment is rolled back.
 
 #### Limits to blue/green deployment
 
@@ -149,4 +201,4 @@ You can [learn more about that configuration format here](environment/serverless
 
 ## Learn more
 
-Read more about `serverless deploy` in [the official documentation](https://serverless.com/framework/docs/providers/aws/guide/deploying/).
+Read more about `serverless deploy` in [the official documentation](https://github.com/oss-serverless/serverless/blob/main/docs/guides/deploying.md).

docs/deploy.mdx

@@ -9,5 +9,6 @@
   "database-public": {
     "display": "hidden"
   },
+  "aws-credentials": "AWS credentials",
   "performances": "Performance"
 }