Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.localops.co/llms.txt

Use this file to discover all available pages before exploring further.

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.

​
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.

​
Environment level vs Service level secrets

Secrets can be added at two levels:
  1. Environment level
  2. Service level
Environment level secrets are global secrets that will get passed into every service within the environment implicitly. Service level secrets are added at the service level and override Environment level secrets wherever the name matches with a environment level secret.

​
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.

​
Built in secrets

Following secrets are passed by default by the platform for convenience.
Secret Key / Environment variableValue
LOPS_SVC_HOSTPublic domain of a service. Applicable for web service.
LOPS_INTERNAL_HOSTPrivate internal host name of a service. Applicable for web or internal services.
LOPS_PREVIEWtrue/false based on whether the service is spun up temporarily for a pull request (PR).
POD_IPIP address assigned to a pod.
HOST_IPIP address assigned to the node where the service is running.

​
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.