Deploy

Dedicated

What an installation is#

An installation is a complete Valet in one dedicated AWS account, with its own network, database, storage and secrets. It shares nothing with other customers or with Valet's cloud. People build the same way they do in the cloud: they publish artifacts, apps and agents with the same CLI, MCP server and dashboard.

Two ways to run it#

Valet runs it for you. Valet sets up a managed, dedicated installation and operates it, including upgrades and monitoring. It runs in an AWS account Valet keeps for you alone. Valet engineers have administrator access to that account to operate it, and each shell session they open into Valet's services is logged in the account.

Your team runs it. Valet engineers ship releases, and your operations team installs and upgrades the installation in your own AWS account, on its own schedule.

Either way, your administrators run your organization: members, connectors, resources and governance, through the dashboard, CLI and MCP server.

To talk about which fits your company, email support@valet.dev.

What runs in the account#

Everything except the load balancer and the NAT gateway sits in private subnets with no public address.

What drives cost#

An installation's AWS bill has a fixed part and a part that grows with use.

• Always on: Valet's services and database, the load balancer and the NAT gateway.
• Agents and apps: each running agent, and each running app process, is its own Fargate task, sized from 0.25 vCPU with 512 MB to 2 vCPU with 4 GB. An idle agent or app stops, and starts again on its next message or request, so a tool nobody is using costs little. A small pool of warm tasks keeps that start quick.
• Builds: an app build runs only while it builds.
• Storage and traffic: grow with what people publish and how often it's opened.

Model calls go to the providers the installation uses, with its own API keys; see Models. The account's Fargate vCPU quota caps how many agents, apps and builds run at once.

Security#

• Two ways in. Only the load balancer and CloudFront face the internet, and both serve HTTPS only. No firewall or IP allowlist sits in front of them; Valet checks sign-in and access on every request.
• No long-lived AWS keys. Valet's services hold no AWS access keys. Each runs under its own IAM role, limited to the installation's own resources.
• No AWS permissions for your tools. Agent and app code runs with no AWS permissions at all.
• Private by default. Agents, apps, builds, databases and storage have no public address, and an app's database accepts connections only from inside the installation.
• Encrypted. Data is encrypted at rest in every store, and Valet encrypts secrets and credentials again before it writes them to its database. Connections to the databases use TLS.

See Security model for credentials, isolation and access.

Models#

Valet works with any model served through an Anthropic-compatible or OpenAI-compatible API: Anthropic's and OpenAI's own models, other providers that offer a compatible API, or a model your company runs behind a compatible endpoint. Valet sets up the providers an installation uses.

Agents and apps call models through Valet's model proxy, which adds the provider's API key, so they never hold it. Prompts, responses and tool results go to the model's provider and nowhere else, and a model that runs inside your network keeps them there. Conversation history stays in the installation.

What leaves the installation#

Outbound traffic leaves through one NAT gateway address, which a system you want the installation to reach can allowlist. Nothing filters it: agents, apps and builds can reach any internet address, so what they can reach inside your systems depends on the credentials they hold.

The installation connects to:

• Model providers, for model calls.
• WorkOS, for sign-in.
• Valet's catalog, when an organization is created or installs a catalog agent.
• Gravatar and Loops, for profile pictures and invitation emails. Gravatar receives a hash of a member's email address.
• The services organizations add: connectors, Slack, and log drains.
• Package registries, such as npm, PyPI and the Go module proxy, when apps build and agents install connectors.
• Optional services, only when turned on: Composio connectors, Firecrawl for drafting a design system from a website, Neon for app databases hosted outside the installation, and Valet's monitoring.

People's browsers also send the dashboard's product analytics and error reports to Valet, with the member's user ID and email.

Sign in and reach it#

An installation has its own domain, <domain>. Everything is served under it:

People sign in through WorkOS, which Valet sets up for the installation.

Dashboard. Open https://dashboard.<domain> and sign in.

CLI. Point the CLI at the installation before you log in, and keep these set for every command:

export VALET_API_URL=https://api.<domain>
export VALET_GATEWAY_URL=https://gateway.<domain>
export VALET_WORKOS_CLIENT_ID=<the installation's client ID>
export VALET_CONFIG_DIR=~/.config/valet-<name>

Then run valet auth login.

Without VALET_WORKOS_CLIENT_ID, valet auth login signs you in to the cloud. Without VALET_GATEWAY_URL, valet console talks to the cloud. VALET_CONFIG_DIR keeps the installation's login apart from a cloud one.

MCP. Add https://api.<domain>/mcp to your client as a custom connector. The Valet plugin for Claude Code and Codex points at hosted Valet, so add the server by its URL instead. MCP sign-in works once Valet has set it up for the installation. See MCP server.