Skip to main content
This guide will explain how to add & use secrets in the environment and inside services. Secrets are sensitive key value pairs that you add at run time to use in your services. You can use secrets to pass credentials to access your database, s3 bucket, OpenAI API, environment name, JWT auth keys, cookie secrets and other environment specific information.
When you save secrets, all secrets are encrypted and stored in your connected cloud account’s secret manager. For example, in AWS, all the secrets are encrypted/stored in Parameter Store.LocalOps only stores the KEY names for reference.

​
Usage & environment vars

LocalOps securely passes each key value pair as environment variable to your service. So you can read them and use in code as you would do for any other environment variable.

​
Sensitive Secrets

All secrets are by default encrypted and stored in your connected cloud account. Sensitive refers to how secrets are handled during build time or runtime in Docker and Kubernetes environments. For example: In Docker builds, by default the secrets are passed using build arguments, while sensitive items are passed using build secrets.

​
How to add/update secrets

​
During service creation

In New Service form, you can see a section called “Secrets”. You can add your key value pairs in that section and create the service. If you don’t have all secrets handy when you are creating the service, you can add them after service created. We don’t deploy a service until you trigger them from UI or via git push.

​
After service creation

Navigate to Environment > Services > Service section to find “Secrets” tab. In there, you can add/update your secrets anytime.

​
Refer global secrets in services

For the secrets added in the global/environment secrets. You can refer them in your service by using the following syntax. For example: If you have DB_HOST, DB_USER secrets in global secrets, you can refer them in your service by using the following syntax: 
DATABSE_URL="postgres://#{$/DB_USER}@#{$/DB_HOST}"

​
Using service alias in secrets

You can also refer to secrets from other services by using the following syntax: For example: If you have API_KEY secret in another service, you can refer it in your service by using the following syntax: 
API_KEY="#{$svc-abc/API_KEY}"
Where $svc-abc is the alias of the service where the secret is defined.

​
Importing other service secrets

You can also import all the secrets defined in another service by using a special key. 
__import_svc:$svc-abc
Use __import_svc as the key and the alias of the service which you want to import as the value. Any secret added in the current service will override the imported secret.

​
Deploy changes

To propagate any change in secrets, you will have to trigger a new deployment in your service. So that your containers can restart with new and updated env vars. Click on “Deploy” on top right corner of the service section, to do a manual deployment from the latest commit of the configured branch. Or push a new commit to the configured branch and git repo.
⌘I