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.

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

​
Expressions in secret values

A secret value can contain #{...} expressions. Each expression is replaced with the value it points to — an environment level secret, another service’s secret, or a service’s in-cluster hostname. Expressions are evaluated anywhere inside the value, not just when the expression is the whole value. So one secret can hold a complete URL instead of being split into separate host/port/path variables. $svc-abc is the alias of a service. You can copy it from the “Overview” tab of that service.

​
Examples

​
What #{$svc-abc} resolves to

A bare alias resolves only when the referenced service actually has an address inside the cluster.

​
Unresolvable expressions

An expression that cannot be resolved is left in the value exactly as written, braces included, and a warning is logged. This applies to an unknown alias, a missing secret key, a service with no internal hostname, and any form that isn’t in the table above.
Each expression is resolved independently — one bad expression does not stop the others in the same value. Braces are deliberately kept so a typo is visible in your pod’s environment, instead of shipping a plausible looking value like http://$svc-242g:8080/x that only fails at runtime.
Expressions are evaluated when you save the secret, not on deploy. Create the services you refer to first, then save the secrets that point at them.
Values are resolved only one level deep. If a referenced secret’s value itself contains $svc- or #{...}, it is passed through as-is. This is intentional, to break reference loops.

​
Bare alias as the whole value

A value that is nothing but an alias, with no braces, still resolves to a hostname:
This is the older form and is supported for backward compatibility. It follows the same rules as #{$svc-abc} above — so a bare alias of a worker, cron, job or Helm chart service stays literal. Prefer #{...} for new secrets.

​
Importing other service secrets

You can also import all the secrets defined in another service by using a special key.
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.

​
Aliases outside secrets

The same alias rules apply everywhere an alias can be used:
  • ops.json init dependency — "type": "service" with "service": "$svc-abc". See Init Jobs. An alias that names no in-cluster service fails the deployment with invalid svc provided as dependency.
  • Helm chart values.yaml — aliases used in the settings of a Helm chart service are replaced with the internal hostname. An alias that doesn’t resolve is left as written.

​
Expressions in generated Helm charts

When LocalOps generates a Helm chart for your environment, #{...} expressions are resolved at chart generation time, with two differences:
  • A referenced secret marked sensitive is not substituted — the expression is left as written. A sensitive value cannot be inlined into another secret’s value in the chart.
  • A referenced secret exposed in the chart renders as a Helm values reference, for example {{ .Values.global.config.pgHost }}, so chart users can override it in their own values.yaml.

​
Built in secrets

Following secrets are passed by default by the platform for convenience.

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