# Starting the server With Vault installed, the next step is to start a Vault server. Vault operates as a client-server application. The Vault server is the only piece of the Vault architecture that interacts with the data storage and backends. All operations done via the Vault CLI interact with the server over a TLS connection. ## Starting the Dev Server 1. Use the `-help` flag to list available command options for `vault server`. ```shell-session $ vault server -help ``` Scroll down to the **Dev Options** section. ```plaintext Dev Options: -dev Enable development mode. In this mode, Vault runs in-memory and starts unsealed. As the name implies, do not run "dev" mode in production. The default is false. -dev-listen-address= Address to bind to in "dev" mode. The default is 127.0.0.1:8200. This can also be specified via the VAULT_DEV_LISTEN_ADDRESS environment variable. -dev-no-store-token Do not persist the dev root token to the token helper (usually the local filesystem) for use in future requests. The token will only be displayed in the command output. The default is false. -dev-root-token-id= Initial root token. This only applies when running in "dev" mode. This can also be specified via the VAULT_DEV_ROOT_TOKEN_ID environment variable. -dev-tls Enable TLS development mode. In this mode, Vault runs in-memory and starts unsealed, with a generated TLS CA, certificate and key. As the name implies, do not run "dev-tls" mode in production. The default is false. -dev-tls-cert-dir= Directory where generated TLS files are created if `-dev-tls` is specified. If left unset, files are generated in a temporary directory. ``` {% hint style="info" %} **TLS option**: If you are running Vault 1.12.0 or later, you can enable TLS with a dev server using the `-dev-tls` flag. {% endhint %} 2. Start a Vault server in development mode (dev server). The dev server is a built-in, pre-configured server that is not very secure but useful for playing with Vault locally. Later in the Deploy Vault tutorial, you will configure and start a non-dev server. ```shell-session $ vault server -dev ``` **Example output:** ```plaintext ==> Vault server configuration: Api Address: http://127.0.0.1:8200 Cgo: disabled Cluster Address: https://127.0.0.1:8201 Go Version: go1.21.4 Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled") Log Level: info Mlock: supported: false, enabled: false Recovery Mode: false Storage: inmem Version: Vault v1.0.0-dev1, built 2023-11-12T14:39:49Z Version Sha: 2a7c3f2f76e6fd6a7f8622ea68d82bcf9dcf9686 ==> Vault server started! Log data will stream in below: # ...snip... WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory and starts unsealed with a single unseal key. The root token is already authenticated to the CLI, so you can immediately begin using Vault. You may need to set the following environment variables: $ export VAULT_ADDR='http://127.0.0.1:8200' The unseal key and root token are displayed below in case you want to seal/unseal the Vault or re-authenticate. Unseal Key: PLV0OXO9VmF5VB8qAnq4pQIGzWkzzYypRNcDtrhSSgU= Root Token: hvs.6j4cuewowBGit65rheNoceI7 Development mode should NOT be used in production installations! ``` You should see an output similar to that above. Notice that **Unseal Key** and **Root Token** values are displayed. The dev server stores all its data in memory (but still encrypted), listens on `localhost` without TLS, and automatically unseals and shows you the unseal key and root access key. Insecure operation Do not run a Vault dev server in production. This approach is only used here to simplify the unsealing process for this demonstration. #### Set environment variables 1. Launch a new terminal session. 2. Copy and run the `export VAULT_ADDR ...` command from the terminal output. This will configure the Vault client to talk to the dev server. ```shell-session $ export VAULT_ADDR='http://127.0.0.1:8200' ``` Vault CLI determines which Vault servers to send requests using the `VAULT_ADDR` environment variable. 3. Save the unseal key somewhere. Don't worry about *how* to save this securely. For now, just save it anywhere. 4. Set the `VAULT_TOKEN` environment variable value to the generated **Root Token** value displayed in the terminal output. **Example:** ```shell-session $ export VAULT_TOKEN="hvs.6j4cuewowBGit65rheNoceI7" ``` To interact with Vault, you must provide a valid token. Setting this environment variable is a way to provide the token to Vault via CLI. Later, in the Authentication tutorial, you will learn to use the `vault login ` command to authenticate with Vault.
Development server with TLS enabled If you wish to run a Vault dev server with TLS enabled, use the `-dev-tls` flag instead of `-dev`. ```shell-session $ vault server -dev-tls ``` **Example output:** ```plaintext ==> Vault server configuration: Api Address: https://127.0.0.1:8200 Cgo: disabled Cluster Address: https://127.0.0.1:8201 Go Version: go1.21.4 Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "enabled") Log Level: info Mlock: supported: false, enabled: false Recovery Mode: false Storage: inmem Version: Vault v1.0.0-dev1, built 2023-11-12T14:39:49Z Version Sha: 2a7c3f2f76e6fd6a7f8622ea68d82bcf9dcf9686 ==> Vault server started! Log data will stream in below: #...snip... WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory and starts unsealed with a single unseal key. The root token is already authenticated to the CLI, so you can immediately begin using Vault. You may need to set the following environment variables: $ export VAULT_ADDR='https://127.0.0.1:8200' $ export VAULT_CACERT='/var/folders/bz/nvj1yk7j411frmff3198l8_c0000gp/T/vault-tls1123544318/vault-ca.pem' The unseal key and root token are displayed below in case you want to seal/unseal the Vault or re-authenticate. Unseal Key: Lylgnqrv+0W6ZO8gzhbnqsaOXcx9Mlgqxxlv641nwZ0= Root Token: hvs.kvlITyyikUb8bPwqS1Nfjx7f Development mode should NOT be used in production installations! ``` The `VAULT_ADDR` is set to use HTTPS protocol. ```shell-session $ export VAULT_ADDR='https://127.0.0.1:8200' ``` Set the TLS certificate location with `VAULT_CACERT`. ```shell-session $ export VAULT_CACERT='/var/folders/bz/nvj1yk7j411frmff3198l8_c0000gp/T/vault-tls1123544318/vault-ca.pem' ``` Set the `VAULT_TOKEN`. ```shell-session $ export VAULT_TOKEN="hvs.kvlITyyikUb8bPwqS1Nfjx7f" ```
### Verify the Server is Running Verify the server is running by running the `vault status` command. If it ran successfully, the output should look like the following: ```shell-session $ vault status Key Value --- ----- Seal Type shamir Initialized true Sealed false Total Shares 1 Threshold 1 Version 1.0.0 Build Date 2023-11-12T10:27:10Z Storage Type inmem Cluster Name vault-cluster-2b0b44fd Cluster ID a6f87c32-fe6a-6647-0d22-e814d125a5c4 HA Enabled false ``` If the output looks different, restart the dev server and try again. The only reason these would ever be different is if you're running a dev server from going through this tutorial previously. ## Next Congratulations! You've started your first Vault server. You can continue with the Your First Secret tutorial, where you will learn how to store secrets in Vault. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.enclaive.cloud/vault/documentation/get-started/starting-the-server.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.