Quickstart
Install a gateway, point a client at it, and verify traffic -- the four steps of the install flow.
Quickstart
Getting traffic into Nautir is a four-step wizard in the dashboard: Install gateway, under Inference Platform, in the Connections group.
The console URL is not settled while Nautir's external surface is being
decided. Wherever this documentation needs one it uses the placeholder
https://<your-nautir-console> -- substitute the address your team was given.
The install flow itself lives at
https://<your-nautir-console>/inference-platform/install.
Every gate in the flow is a real signal. An installation must be prepared before you can leave the install step, and every connection track you selected must signal before you can finish.
Select deployment
Choose where the gateway will run. You will name and install it in the next step.
| Option | When to choose it |
|---|---|
| Helm / K8s | The recommended production choice. Deploy to your own cluster with the chart; prompts stay in your own network. |
| DevZero-hosted | For trials. DevZero runs the gateway and you point any client at a provisioned URL. |
| Docker | Run anywhere with docker run or compose. |
| Docker Compose | Declarative YAML for local machines, VMs or simple server deploys. |
Helm is the default because prompts and retrievable originals stay inside your network. Hosted is for proofs of concept and trials.
Install gateway
Name your installation, then generate the command that carries its gateway credentials. On hosted, this step provisions a dedicated DevZero-hosted gateway instead.
Use an installation name that identifies the environment or team using this
gateway -- for example prod-us-east.
This step mints a personal access token and an installation row, so it runs only when you press the button. Re-entering the flow for an existing installation never re-runs it.
The generated command carries what the gateway needs: your team id, its auth token, the control-plane endpoint it reports to, the installation id and name, and the image to run. The gateway makes outbound connections to the control plane to send telemetry, so allow outbound HTTPS from wherever it runs.
The dashboard generates a command of this shape. Copy the real one -- it comes pre-filled with your own ids.
helm install devzero-llm-proxy oci://registry-1.docker.io/devzeroinc/llm-proxy \
--namespace devzero-system --create-namespace \
--set image.repository=devzeroinc/llm-proxy \
--set image.tag=<TAG> \
--set config.teamID=<TEAM_ID> \
--set config.authToken=<AUTH_TOKEN> \
--set config.backendEndpoint=<BACKEND_ENDPOINT> \
--set config.installationId=<INSTALLATION_ID> \
--set config.installationName=<INSTALLATION_NAME>See Self-hosting for what the chart brings with it -- two Redis instances, a disruption budget, a replica floor and the upgrade operator, which is on by default.
Connect to your gateway
Pick what you are connecting. You can do both, and most teams want both.
| Track | What it is | Who pays |
|---|---|---|
| Coding tools | Point Claude Code, Codex, Cursor and friends at the gateway with a base-URL swap. | Your provider subscriptions keep paying. DevZero observes and optimizes. |
| API access | Issue an sk-dz- key for your own apps, agents and CI. One endpoint, with budgets, guardrails and routing applied. | The credential your key's custody resolves to. |
The two verify differently, because they are different traffic: coding tools verify on any request reaching the installation, while API access verifies only on that key's own first use.
See Connect coding tools and API access.
Verify traffic
Send your first request. The wizard shows it within a few seconds.
Verification is passive on both tracks: the wizard polls and waits for a request you make yourself, because nothing in the product may originate a model request on your behalf.
Two signals stream into this step:
| Signal | Meaning |
|---|---|
| Gateway connected | The heartbeat has arrived. The gateway is reachable and reporting. |
| Traffic detected | A real request has flowed through. |
These are genuinely independent. A gateway can be connected and idle -- connectivity is a heartbeat property and says nothing about traffic. A source is shown as Live when it has had at least one request in a fixed recent window of 24 hours, independent of the page's time picker. A connected gateway with no traffic in that window reads Idle; a source with none at all reads No data.
If you want to come back to it, the flow offers an explicit escape: you can verify later, and returning a gateway to this view is always available from its entry on the Sources screen.
After the flow
The install flow is per gateway. Three things are team-wide, available any time, and deliberately not gates in the wizard:
| Next step | Where | Why |
|---|---|---|
| Connect provider accounts | Provider keys | The credentials your traffic forwards with, and the read-only accounts your invoices are reconciled against. |
| Link identities | People, on its linking tab | Resolves the vendor-side identities the gateway observes onto real people, so attribution names humans. |
| Read the contract | API reference | Generated from the gateway's own OpenAPI document, so there is no second copy to drift. |
Where your traffic shows up
| Group | Screens |
|---|---|
| Overview | The section landing page: headline spend and volume, spend by provider, volume over time, top models and users, and the anatomy of what you are paying for. |
| Usage | Traces, Sessions, Efficiency, Spend. |
| Attribution | People, Teams, Departments, Services, Seats. |
| Evals | Live, Results, Trials, Watches, Compare, Datasets. |
| Access | API keys, Authorized clients, Guardrails, Governance. |
| Routing | Catalog, Providers, Profiles. |
| Connections | Sources, Provider keys, Install gateway, API reference. |
The optimization journey has no navigation entry of its own -- the journey pill in every Inference Platform page header is its entry point. See the journey.