Adios
Data services · plans from $10/month

Deploy Qdrant.Protect the vector store and verify retrieval.

Start a pinned single-node Qdrant service, persist collections and snapshots, separate administrator and read-only access, and test representative vector queries.

Deploy my projectDeploy a template
Keep the repositoryInspect build and logsCustom domains and TLS
Adios deploy

Candidate release

Qdrant

Healthy

SOURCE

Git

REGION

de

ROUTE

HTTPS

01Source received

02Build completed

03Runtime started

04Health check passed

Promoted route

production.adios.run

A production path for

Qdrant 1.19.0Vector databaseREST + gRPCGenerated keysPersistence

The production path

A working Qdrant project still needs a safe release.

The application or service is only one part of production. Build evidence, runtime state, health, secrets, logs, routes, and the promoted version should remain inspectable together.

Start Qdrant from a versioned template

The official template downloads the Qdrant 1.19.0 static binary for amd64 or arm64, verifies its pinned checksum, and generates separate administrator and read-only API keys.

Make persistence an explicit decision

Collections, indexes, and local snapshots live under /app/qdrant-data on persistent storage. Back up that volume and test snapshot recovery before relying on it for production retrieval.

Keep service state visible to operators

Use /healthz for readiness, exercise REST or gRPC with representative vectors and filters, and keep every API key on HTTPS or a private network path.

From source to release

Three steps keep the deployment path reviewable.

Use the source and production behavior the project already has. The manifest records what the platform should build or provision and how the result becomes ready.

  1. 01

    Start with source or a template

    Bring the existing repository, or inspect and deploy one of the exact starter variants linked below.

    $adios login
  2. 02

    Review the deployment contract

    Keep commands, runtime or service version, health behavior, and secret references in adios.yaml.

    $git diff -- adios.yaml
  3. 03

    Deploy and inspect the result

    Follow build and runtime evidence, verify the candidate, and open the promoted route or service connection.

    $adios up
adios.yaml
Your project
type: database
secrets:
  QDRANT_API_KEY: secret://generate:64
  QDRANT_READ_ONLY_API_KEY: secret://generate:64
build_cmd: sh /app/install-qdrant.sh
start_cmd: exec /app/qdrant-server --config-path /app/qdrant.yaml
port:
  - 6333
  - 6334

runtime:
  health_path: /healthz
  volumes:
    - name: qdrant-data
      target: /app/qdrant-data
      persistent: true
The complete starter disables clustering, remote snapshot URLs, and usage telemetry for its deliberate single-node baseline.

Deployable starting points

Start Qdrant from a template when the repository is not ready.

Inspect the complete Qdrant starter, clone its standalone repository, or deploy it directly with the public qdrant key.

Data services

Qdrant 1.19.0

Qdrant 1.19.0 with persistent vector data and generated administrator and read-only keys.

Vector APIUpstream release
Template key
qdrant
Runtime
pinned binary
Repository
template-qdrant
Source path
.
git clone https://github.com/adiosdotdev/template-qdrant.git
cd template-qdrant
adios up
DeployView source
Review the template deployment flow

Before production

Verify the workload.Then promote it.

The safest first release starts with a reproducible build or service configuration and a preview that exercises the dependencies production will actually use.

Ready when…

  • Administrator and read-only clients use separate keys.
  • Vector dimensions and distance metrics are intentional.
  • Representative writes, filters, and searches pass.
  • Snapshot and restore ownership is documented.

Preview when…

  • An embedding model changes vector dimensions.
  • A collection rebuild or bulk import changes disk demand.
  • The workload needs multi-node high availability.

Questions, answered

What to know before deploying Qdrant.

Review the runtime or service boundary, template path, failure behavior, and production checks before creating the first release.

Can I deploy Qdrant from an official template?

Yes. Choose the Qdrant template that matches the version or configuration you need, store credentials as Adios secrets, and deploy it from the console or with adios up.

Does the Qdrant template use persistent storage?

Collections, indexes, and local snapshots live under /app/qdrant-data on persistent storage. Back up that volume and test snapshot recovery before relying on it for production retrieval.

Which Qdrant ports does the template expose?

The REST API and dashboard use port 6333, while gRPC uses port 6334. The primary HTTPS route serves the REST surface; connect gRPC only through an approved network path.

Is this a clustered Qdrant deployment?

No. The starter is an explicit single-node baseline. Design and test a dedicated multi-node topology when the workload requires high availability beyond restart persistence.

Where should database and broker passwords be stored?

Store sensitive values in Adios secrets and reference them with secret://NAME. Do not place production credentials directly in adios.yaml or commit them to Git.

What should I verify before production traffic?

Verify authentication, application connectivity, write and read behavior, restart persistence, backup or recovery expectations, capacity, and the failure behavior of every dependent application.

Related deployment paths

Connect the rest of the stack.

Browse all deployment pages

Deploy Typesense

Start a pinned Typesense server, persist collections and documents, protect the bootstrap administrator key, and verify indexing plus search before launch.

Deploy pgvector

Start PostgreSQL with the pgvector extension, connect an embedding application, verify vector writes and nearest-neighbor queries, and test persistence.

Deploy FastAPI

Deploy a FastAPI service with its ASGI import target, dependency install, runtime port, health endpoint, secrets, and promoted release tied to source.

Deploy Node.js

Deploy a persistent Node.js web process or worker from its existing package scripts, with release health, logs, secrets, routing, and Git history attached.

The first release

Deploy Qdrant with the source and evidence attached.

Start from the repository or a template, review the deployment contract, and inspect what becomes the promoted production version.

Start with AdiosCompare plans