Evaluate

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 sits in private subnets with no public address. The load balancer is internal, so nothing in the installation faces the internet.

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 your VPC provides.
• 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#

• No way in from the internet. The installation has one internal load balancer on private subnets. People reach it from your network or your VPN, over HTTPS only, and 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#

An installation calls Anthropic's API with your company's own API key.

Agents and apps call models through Valet's model proxy, which adds the API key, so they never hold it. Prompts, responses and tool results go to Anthropic and nowhere else. 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:

• Anthropic, for model calls.
• WorkOS, for sign-in.
• AWS service endpoints, for the services in the table above.
• Valet's release bucket and image registry, when you install or upgrade.
• The services organizations add: connectors, Slack, and log drains.
• Custom checker endpoints, when an organization adds a custom release checker. Each receives links to the files of the releases a policy evaluates.
• OSV.dev, when an organization adds a Dependencies (OSV) release policy. It receives each package's ecosystem, name and version.
• 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, and Neon for app databases hosted outside the installation.

An installation sends no profile pictures to Gravatar and no email to Loops. People's browsers send no product analytics or error reports to Valet.

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. The hosts resolve inside the VPC. A laptop on your office network or VPN reaches them once its resolver forwards the installation's domain to the VPC.

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.

Next steps#

• Security model: review access controls and credential handling.
• Connect to your installation: configure your agent after your administrator sets it up.