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

# Secrets

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.

<Note>
  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.
</Note>

## 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](environment/services/micro-services#using-service-alias-as-hostname)
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.

```bash theme={null}
__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 variable | Value                                                                                                                                                                                                                                              |
| --------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `LOPS_SVC_HOST`                   | Public domain of a service. Applicable for `web` service.                                                                                                                                                                                          |
| `LOPS_INTERNAL_HOST`              | Private internal host name of a service. Applicable for `web` or `internal` services.                                                                                                                                                              |
| `LOPS_PREVIEW`                    | `true`/`false` based on whether the service is spun up temporarily for a pull request (PR).                                                                                                                                                        |
| `POD_IP`                          | IP address assigned to a pod.                                                                                                                                                                                                                      |
| `HOST_IP`                         | IP address assigned to the node where the service is running.                                                                                                                                                                                      |
| `DEPLOYMENT_ID`                   | A 24-character alphanumeric string that uniquely identifies the environment (as unique as a UUIDv4). For environments managed by LocalOps, this is unique per environment; for Helm charts generated by LocalOps, this is unique per Helm install. |
| `LOPS_INSTANCE_ID`                | Same value as `DEPLOYMENT_ID`. A 24-character alphanumeric string that uniquely identifies the environment or Helm install.                                                                                                                        |

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