Environment variables

Environment variables for a project are set in ScaleBop, on the project’s Configuration step. Analysis lists keys it found in the repository. You supply the values. Those values are stored for the deployment. They are not committed to your repository.

Shared and per-deployable values

A project can have more than one deployable (for example a web app and an API in the same repo).

• Use one shared value when every selected deployable should receive the same setting.
• Use per-deployable values when the same key must differ between packages.

You can continue past Configuration with keys still missing. A missing value often shows up later as a failed start or a health check error. You can return to Configuration and fill them in at any time.

Plain values and secrets

Each variable is either plain or secret.

• Plain values are ordinary configuration.
• Secret variables must point at an AWS Secrets Manager or SSM reference. Do not paste a secret into the repository or into a generated file.

After a deployment, ScaleBop-managed secrets may exist in AWS Secrets Manager with a temporary placeholder. Replace that placeholder before you treat the app as production:

1. AWS Console → Secrets Manager → the secret → Retrieve secret value → Edit.
2. Or put the value with the CLI. The secret id follows scalebop/<project-id>/<KEY> in the project’s region.

Refresh AWS status on the Configuration page after you change a secret in AWS.

Where each variable ends up

ScaleBop copies your values to your GitHub repository’s Actions settings: plain values become variables and secrets become secrets. It also writes a variable named SCALEBOP_ENV_MANIFEST. That variable lists your keys and the names of your secrets, never their values. The deploy workflow reads them from there.

In the build

Keys that start with NEXT_PUBLIC_, VITE_, NUXT_PUBLIC_, REACT_APP_, EXPO_PUBLIC_ or GATSBY_ are passed to your build, for example VITE_SUPABASE_URL for a Vite app or NEXT_PUBLIC_SUPABASE_URL for a Next.js export. Your framework builds these values into the files it sends to the browser, so anyone can read them. Only use these prefixes for values that are safe to make public.

The workflow names each build key it passes. If you add a new key with one of these prefixes after your deploy files were generated, regenerate them so the build picks it up.

In the running app

If your app has a server part (a Lambda function, an ECS Fargate service or an Elastic Beanstalk environment), every key you set reaches it when it runs. Keys without a public prefix only go here.

• Plain values are set as ordinary environment variables.
• Secrets are referenced by name, so the value is never written into your repository, the generated code, the CloudFormation template or the deploy logs. Fargate reads the secret when a container starts, and its execution role can read only the secrets your app uses. On Lambda and Elastic Beanstalk, AWS fills in the value during the deploy.
• Lambda and Elastic Beanstalk can only read secrets from AWS Secrets Manager. For those, use a Secrets Manager secret rather than an SSM parameter.

To change a value, update it on the Configuration page (or in AWS Secrets Manager) and deploy again. Adding or removing a key works the same way. You don’t need to regenerate anything.

Before the deploy changes anything in AWS, a Check app secrets step confirms each secret exists. If one is missing, the deploy stops and names it. A key you added without a value shows a warning, and the app starts without it.

Static sites

A static site has no server, so only keys with a public prefix reach it. A secret without one would end up in public files, so the deploy stops with an error rather than building it in. Move the code that needs it to a server or API, or delete the variable on the Configuration page.