The Vault UI is a web application that lets you interact with Vault without needing to use the command line.

Let’s see it in action. Imagine you have Vault running and you want to access its UI. You’d typically point your browser to http://127.0.0.1:8200/ui/. If Vault is configured to listen on a different address or port, you’d use that. For example, if Vault is on vault.mydomain.com and listening on port 443, you’d go to https://vault.mydomain.com/ui/.

The Vault UI is served directly by the Vault server process. There’s no separate UI server to install or manage. When Vault starts, it checks its configuration for settings related to the UI. If enabled, it will serve static assets (HTML, CSS, JavaScript) for the UI from its own binary. This means that to change the UI, you’d typically need to update your Vault binary and restart the server.

The core problem the UI solves is making Vault accessible to a broader audience. Instead of requiring users to learn vault CLI commands and understand its JSON output, they can use a familiar graphical interface for common tasks like:

  • Authentication: Logging in with various auth methods (AppRole, Kubernetes, LDAP, etc.).
  • Secrets Management: Browsing, creating, reading, and deleting secrets in different engines.
  • Policy Management: Viewing and editing access control policies.
  • Audit Device Configuration: Inspecting and managing audit logs.
  • Health Checks: Monitoring Vault’s operational status.

The UI is enabled by default when Vault is running in development mode. In production, it’s often controlled via a configuration file. Here’s a snippet of a vault.hcl configuration file that explicitly enables the UI:

listener "tcp" {
  address = "0.0.0.0:8200"
  tls_disable = 1
}

ui = true

The ui = true stanza tells the Vault server to also serve the UI assets. If ui is set to false or omitted, the UI will not be available. The UI is served on the same network address and port that Vault is listening on, typically appended with /ui/.

When you navigate to the UI’s URL, your browser downloads these static assets from the Vault server. The JavaScript then makes API calls back to the Vault server’s API endpoints to fetch and display data, and to perform actions. This means the UI’s functionality is directly tied to the Vault server’s capabilities and the specific API version it’s running.

The UI is designed to be stateless from the server’s perspective. All state is managed by the Vault server itself. The UI is essentially a client that communicates with the Vault API. This design choice simplifies Vault’s internal architecture and allows the UI to be easily scaled or replaced without impacting Vault’s core operations.

If you’re running Vault behind a reverse proxy, like Nginx or Traefik, you’ll need to configure that proxy to correctly route requests to the /ui/ path to your Vault server. For example, in Nginx, you might have a configuration like this:

server {
    listen 443 ssl;
    server_name vault.mydomain.com;

    # ... SSL configuration ...

    location /ui/ {
        proxy_pass http://127.0.0.1:8200/ui/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location / {
        proxy_pass http://127.0.0.1:8200/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

This ensures that both the UI assets and API requests are correctly forwarded.

The Vault UI’s version is tightly coupled to the Vault server version. When you upgrade Vault, you’re also upgrading the UI. There isn’t a separate mechanism to update just the UI components independently. This ensures consistency between the interface and the backend functionality.

Understanding how the UI is served by the Vault server itself is key to troubleshooting. If the UI isn’t loading, it’s not a DNS issue with a separate UI service, but rather a direct problem with the Vault server’s ability to serve those assets or a network path issue to the Vault server.

The next step after getting the UI set up is often configuring TLS for secure access.

Want structured learning?

Take the full Vault course →