Skip to content

Deploy Apps with Postgres, Redis, MongoDB, and MySQL

Varity Team Core Contributors Updated June 2026

When your code needs a database, Varity provisions one in the same deployment and injects the connection details. You don’t create accounts, copy connection strings, or wire anything up. This page explains what you get and, importantly, what the durability boundary is in beta.

Varity detects these from your dependencies and provisions them alongside your app:

Postgres

Relational database, with pgvector for embeddings. Injected as DATABASE_URL.

Redis

In-memory cache / store. Injected as REDIS_URL.

MongoDB

Document database. Injected as MONGODB_URI.

MySQL

Relational database. Injected as MYSQL_URL.

Varity also provisions an Ollama model server (OLLAMA_URL) and an S3-compatible object store (MINIO_URL, MINIO_ACCESS_KEY, MINIO_SECRET_KEY) when your app uses one. Detection and the full env-var list are covered in Auto-wired Services.

Your app reads these from its environment. No connection strings to manage:

// Varity injects DATABASE_URL; just read it
const db = process.env.DATABASE_URL;

What this means in practice:

  • Good for: demos, prototypes, side projects, and apps that tolerate beta.
  • For business-critical data: bring your own external managed database (point your app at it via an environment variable) until Varity’s managed-database durability ships. Your app deploys exactly the same way. It just connects to your database instead of an auto-wired one.

To use an external database, set its connection string as an environment variable (for example DATABASE_URL) when you deploy, and Varity won’t provision its own. See Environment Variables.