+ 
+
+ 
+
+ 
+
+ 
+
+ 
+
+ 
+
+ 
+
-The most common next steps are to move to a persistent database, configure
-authentication, and add a plugin:
+In the next part of this tutorial, you'll learn how to change to a persistent
+database, configure authentication, and add your first integration. Continue
+with [getting started: Configuring Backstage](configuration.md).
-- [Switching from SQLite to PostgresQL](https://backstage.io/docs/tutorials/switching-sqlite-postgres)
-- [Setting up Authentication](https://backstage.io/docs/auth/)
-- [Adding a plugin](https://backstage.io/docs/getting-started/configure-app-with-plugins)
-
-Congratulations! That should be it. Let us know how it went:
+Share your experiences, comments, or suggestions with us:
[on discord](https://discord.gg/EBHEGzX), file issues for any
[feature](https://github.com/backstage/backstage/issues/new?labels=help+wanted&template=feature_template.md)
or
diff --git a/docs/getting-started/keeping-backstage-updated.md b/docs/getting-started/keeping-backstage-updated.md
index ffe4f4dcd5..107119aace 100644
--- a/docs/getting-started/keeping-backstage-updated.md
+++ b/docs/getting-started/keeping-backstage-updated.md
@@ -22,6 +22,13 @@ yarn backstage-cli versions:bump
The reason for bumping all `@backstage` packages at once is to maintain the
dependencies that they have between each other.
+If you are using other plugins you can pass in the `--pattern` option to update
+more than just the `@backstage/*` dependencies.
+
+```bash
+yarn backstage-cli versions:bump --pattern '@{backstage,roadiehq}/*'
+```
+
## Following create-app template changes
The `@backstage/create-app` command creates the initial structure of your
diff --git a/docs/integrations/aws-s3/locations.md b/docs/integrations/aws-s3/locations.md
index fe1c6050c2..b0c6829e2c 100644
--- a/docs/integrations/aws-s3/locations.md
+++ b/docs/integrations/aws-s3/locations.md
@@ -20,8 +20,7 @@ To use this integration, add configuration to your `app-config.yaml`:
```yaml
integrations:
awsS3:
- - host: amazonaws.com
- accessKeyId: ${AWS_ACCESS_KEY_ID}
+ - accessKeyId: ${AWS_ACCESS_KEY_ID}
secretAccessKey: ${AWS_SECRET_ACCESS_KEY}
```
@@ -35,8 +34,21 @@ instruct the AWS S3 reader to assume a role before accessing S3:
```yaml
integrations:
awsS3:
- - host: amazonaws.com
- accessKeyId: ${AWS_ACCESS_KEY_ID}
+ - accessKeyId: ${AWS_ACCESS_KEY_ID}
secretAccessKey: ${AWS_SECRET_ACCESS_KEY}
roleArn: 'arn:aws:iam::xxxxxxxxxxxx:role/example-role'
```
+
+Configuration allows specifying custom S3 endpoint, along with
+[path-style access](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html)
+to support integration with providers like
+[LocalStack](https://github.com/localstack/localstack):
+
+```yaml
+integrations:
+ awsS3:
+ - endpoint: 'http://localhost:4566'
+ s3ForcePathStyle: true
+ accessKeyId: ${AWS_ACCESS_KEY_ID}
+ secretAccessKey: ${AWS_SECRET_ACCESS_KEY}
+```
diff --git a/docs/local-dev/cli-commands.md b/docs/local-dev/cli-commands.md
index 318b37f34e..caec60ed70 100644
--- a/docs/local-dev/cli-commands.md
+++ b/docs/local-dev/cli-commands.md
@@ -434,7 +434,8 @@ Usage: backstage-cli build [options]
Options:
--outputs <formats> List of formats to output [types,cjs,esm]
- -h, --help display help for command
+ --minify Minify the generated code
+ -h, --help display help for command
```
## lint
@@ -593,6 +594,7 @@ Usage: backstage-cli versions:bump [options]
Options:
-h, --help display help for command
+ -p, --pattern Override glob for matching packages to upgrade
```
## versions:check
diff --git a/docs/overview/architecture-overview.md b/docs/overview/architecture-overview.md
index 3425b02db9..d3f171e4f8 100644
--- a/docs/overview/architecture-overview.md
+++ b/docs/overview/architecture-overview.md
@@ -164,12 +164,104 @@ https://circleci.com.
+## Package Architecture
+
+Backstage relies heavily on NPM packages, both for distribution of libraries,
+and structuring of code within projects. While the way you structure your
+Backstage project is up to you, there is a set of established patterns that we
+encourage you to follow. These patterns can help set up a sound project
+structure as well as provide familiarity between different Backstage projects.
+
+The following diagram shows an overview of the package architecture of
+Backstage. It takes the point of view of an individual plugin and all of the
+packages that it may contain, indicated by the thicker border and italic text.
+Surrounding the plugin are different package groups which are the different
+possible interface points of the plugin. Note that not all library package lists
+are complete as packages have been omitted for brevity.
+
+
+
+### Overview
+
+The arrows in the diagram above indicate a runtime dependency on the code of the
+target package. This strict dependency graph only applies to runtime
+`dependencies`, and there may be `devDependencies` that break the rules of this
+table for the purpose of testing. While there are some arrows that show a
+dependency on a collection of frontend, backend and isomorphic packages, those
+still have to abide by important compatibility rules shown in the bottom left.
+
+The `app` and `backend` packages are the entry points of a Backstage project.
+The `app` package is the frontend application that brings together a collection
+of frontend plugins and customizes them to fit an organization, while the
+`backend` package is the backend service that powers the Backstage application.
+Worth noting is that there can be more than one instance of each of these
+packages within a project. Particularly the `backend` packages can benefit from
+being split up into smaller deployment units that each serve their own purpose
+with a smaller collection of plugins.
+
+### Plugin Packages
+
+A typical plugin consists of up to five packages, two frontend ones, two
+backend, and one isomorphic packages. All packages within the plugin must share
+a common prefix, typically of the form `@