---
# System prepended metadata

title: Daytona

---

# Daytona

Creating this PR as a set of notes for myself, even if it'd be nice to put this upstream.

## Background

Storing multiple keys in a single Vault path is a common use case. e.g. the following JSON can be stored in `secrets/myapp/dev/creds`:

```json
{
  "DB_USER": "postgresuser",
  "DB_PASSWORD": "databasep@ssw0rdSuperSecret"
}
```

```shell
vault write secrets/myapp/dev/creds @example-secrets.json
```

This results in a single secret witih multiple keys (fields) under `secrets/myapp/dev/creds`. 

```shell
vault read secrets/myapp/dev/creds
```

## Current Behavior: Singular mode


For a secret at Vault path `project/someapp/dev/creds`, which contains:

```json
{
  "DB_USER": "postgresuser",
  "DB_PASSWORD": "databasep@ssw0rdSuperSecret"
}
```



| Daytona Env Var | Mode | Value | Resulting Key Name (Prefix)    |
| --------------- | --------------- | -------------- | --- |
| `VAULT_SECRET_APP`            | Singular            | `project/someapp/dev/creds`           |   `creds_` (e.g. `creds_DB_USER`, `creds_DB_PASSWORD`)  |
| `VAULT_SECRET_APP`            | Singular            | `project/someapp/dev/creds/`           |   Prefixed with `_` (e.g. `_DB_USER`, `_DB_PASSWORD`) |


**Resulting Key Name**: The string that will be used as the key when Daytona either loads your secrets as env vars or into a file. Daytona creats a prefix using the end of the path and an underscore. **IMPORTANT: If the path you pass to Daytona ends in `/`, then the end of the path is parsed as an empty string, leading to a prefix of `_`.**

### Example resulting key names:

#### `creds_`

e.g. as env variables (`-secret-env`)

```shell
creds_DB_USER=postgresuser
creds_DB_PASSWORD=databasep@ssw0rdSuperSecret
```

e.g. JSON file:

```json
{
  "creds_DB_USER": "postgresuser"
  "creds_DB_PASSWORD": "databasep@ssw0rdSuperSecret"
}

```

#### `_`

**Daytona will always append an underscore, even to an empty string.**

e.g. as env variables (`-secret-env`)

```shell
_DB_USER=postgresuser
creds_DB_PASSWORD=databasep@ssw0rdSuperSecret
```

e.g. JSON file:

```json
{
  "_DB_USER": "postgresuser"
  "_DB_PASSWORD": "databasep@ssw0rdSuperSecret"
}

```


## Practical Implication

This means that having a single secret with many keys (such as JSON) will:
* prefix your secrets in Daytona with AT LEAST an underscore, meaning that you would need to remap your env var names to the env var names that your application expects


---

## Inconsistency w/ terminology: Vault fields, names, keys

[JSON](https://www.json.org/json-en.html) officially calls the key name in the object k/v as "names", but in conversation "JSON keys" is widely used over "JSON name".

In the official Vault UI (1.7.1), you can toggle between the JSON representation of a single secret and a UI with input text forms for key and value. 