Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: flightcontrol.md

id: flightcontrol title: Deploying with Flightcontrol sidebar_label: AWS Fargate via Flightcontrol description: Deploying Backstage to AWS Fargate via Flightcontrol This guide explains how to deploy Backstage to , a platform that fully automates deployments to Amazon Web Services (AWS). Flightcontrol supports git-driven and image registry deployments. Before you begin, make sure you have a and a to follow this guide. Once your Flightcontrol account is setup, you will need to prepare a `Dockerfile` and `.dockerignore` to deploy Backstage to your target AWS environment. The standard `Dockerfile` included in the Backstage repository assumes that the `skeleton.tar.gz` and `bundle.tar.gz` already exist. When integrating Flightcontrol directly with a GitHub repository, changes to files within this repository will automatically start a Flightcontrol deployment, unless you have configured deployments via a webhook. Regardless of which method you have chosen, when Flightcontrol starts a deployment process it will pull all files directly from the repository, and not from a GitHub runner or other location. As Flightcontrol does not contain CI steps this results in the zip files having to be committed to the repository in order to be available for the `Dockerfile` to copy. A simple work around for this is to use a `Dockerfile` with a . Using this approach we can create our zip files in the first build stage, and copy them into the second stage ready for deployment. The following two code snippets demonstrate this method. The first block of code is an example of a multi-stage build approach and should be added to a file called `Dockerfile.flightcontrol` in the `packages/backend` directory. ```dockerfile filename="Dockerfile.flightcontrol" FROM node:18-bookworm-slim as build USER node WORKDIR /app COPY --chown=node:node . . RUN yarn install --frozen-lockfile RUN yarn tsc RUN yarn build:backend --config ../../app-config.yaml FROM node:18-bookworm-slim RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \ --mount=type=cache,target=/var/lib/apt,sharing=locked \ apt-get update && \ apt-get install -y --no-install-recommends python3 g++ build-essential && \ yarn config set python /usr/bin/python3 RUN --mount=type=cache,target=/var/cache/apt,sharing=locked \ --mount=type=cache,target=/var/lib/apt,sharing=locked \ apt-get update && \ apt-get install -y --no-install-recommends libsqlite3-dev USER node WORKDIR /app ENV NODE_ENV production COPY --from=build app/yarn.lock app/package.json app/packages/backend/dist/skeleton.tar.gz ./ RUN tar xzf skeleton.tar.gz && rm skeleton.tar.gz RUN --mount=type=cache,target=/home/node/.cache/yarn,sharing=locked,uid=1000,gid=1000 \ yarn install --frozen-lockfile --production --network-timeout 300000 COPY --from=build app/packages/backend/dist/bundle.tar.gz app/app-config*.yaml ./ RUN tar xzf bundle.tar.gz && rm bundle.tar.gz CMD ["node", "packages/backend", "--config", "app-config.yaml", "--config", "app-config.production.yaml"] ``` In order to prevent the default `.dockerignore` file from preventing the copying of the relevant files into the first stage of our build, we need to override it with a custom one. This can also be added to the `packages/backend` directory, it should be called `Dockerfile.flightcontrol.dockerignore` and contain the following. ```ssh filename="Dockerfile.flightcontrol.dockerignore" .git .yarn/cache .yarn/install-state.gz node_modules packages/*/node_modules

``` With these two new files, you will now have the necessary steps in place to build the zip files, copy them into the second stage of the build, and deploy them via Flightcontrol. Our next steps before switching to the Flightcontrol dashboard is to create a custom app-config.production file. The purposes of this is to update how Backstage will connect to the RDS hosted Postgres DB. The default `app-config.production` file uses the `host`, `port`, `user` and `password` environment variables. When creating a database via the Flightcontrol dashboard, we are given an environment variable with the single connection string. Therefore we need an `app-config.production` file which uses this variable. Within your Backstage project create a new file called `app-config.production.flightcontrol.yaml`. Add the following configuration to it: ```yaml filename="app-config.production.flightcontrol.yaml" app: baseUrl: http://localhost:7007 backend: baseUrl: http://localhost:7007 listen: ':7007' database: client: pg pluginDivisionMode: 'schema' connection: connectionString: ${POSTGRESCONSTRING} ssl: require: true rejectUnauthorized: false catalog: locations: [] ``` Make a note of the environment variable used in the `connectionString`. In our example above this is `POSTGRESCONSTRING`. You will need this later when you have deployed the database via the Flightcontrol console, and wish to connect to it from Backstage. Ensure that custom `Dockerfile.flightcontrol`, `Dockerfile.flightcontrol.dockerignore` and `app-config.production.flightcontrol.yaml` have been committed to your repository before following the next steps. Login into the Flightcontrol Dashboard and complete each of the following: Create a new project from the Flightcontrol Dashboard Select the GitHub repo for your Backstage project Select `GUI` as the config type: Then, choose `+ Add Web Server (Fargate)` under Services before entering the following server information: | Field Name | Value | | -- | -- | | Build Type | Custom Dockerfile | | Health Check Path | /catalog | | Port | 7007 | Click `Create Project` and complete any required steps (like linking your AWS account). Remember to point the project to your custom files. Create a new project from the Flightcontrol Dashboard Select the GitHub repo for your Backstage project Select the `flightcontrol.json` Config Type. Update the example JSON below where applicable to your custom Dockerfile. ```json filename="flightcontrol.json" { "$schema": "https://app.flightcontrol.dev/schema.json", "environments": [ { "id": "backstage", "name": "Backstage", "region": "us-west-2", "source": { "branch": "main" }, "services": [ { "id": "backstage", "name": "Backstage", "type": "fargate", "buildType": "docker", "dockerfilePath": "Dockerfile", "dockerContext": ".", "healthCheckPath": "/catalog", "cpu": 0.5, "memory": 1, "domain": "backstage.yourapp.com", "port": 7007, "minInstances": 1, "maxInstances": 1 } ] } ] } ``` If you need a database or Redis for your Backstage plugins, you can easily add those to your Flightcontrol deployment. For more information, see . When creating a Postgres RDS database you will need to update the connection string variable name to the one included in the `app-config.production.flightcontrol.yaml`. As noted above in our example we called this `POSTGRESCONSTRING`.