How to install Turso on a VPS

Prerequisites

Start with Ubuntu 22.04 or 24.04, SSH access, a public IP and at least 1 GB of RAM. Use a dedicated hostname such as db.example.com, but do not expose a database protocol directly to the public internet unless the official server documentation requires it.

Read the current Turso and libSQL self-hosting documentation before choosing this path. Managed Turso features, the CLI control plane and a standalone libSQL server are not automatically interchangeable. You need encrypted off-host backups and a plan for schema migrations.

Step 1, Connecting to your server

Patch the VPS and create a private data directory:

ssh root@SERVER_IP
apt update && apt upgrade -y
apt install -y ca-certificates curl
mkdir -p /opt/libsql/data
cd /opt/libsql
chmod 750 /opt/libsql

Keep SSH restricted to administrators. If clients connect over the network, use a private network or VPN whenever possible. Do not put database credentials in shell history.

Step 2, Installing Docker and Docker Compose

Install Docker Engine and the Compose plugin from Docker's official Ubuntu instructions:

docker --version
docker compose version
systemctl enable --now docker

Confirm that the data disk is persistent and has enough free space. SQLite-style databases can grow quickly when write-ahead logs and backups are retained.

Step 3, Running the official libSQL-compatible server

Use the current official libSQL server image or binary from the Turso/libSQL documentation. Do not guess the image name or a release tag. Put the verified value in .env:

LIBSQL_IMAGE=REPLACE_WITH_THE_CURRENT_OFFICIAL_IMAGE
LIBSQL_TOKEN=REPLACE_WITH_A_LONG_RANDOM_VALUE

A minimal Compose shape is:

services:
  libsql:
    image: ${LIBSQL_IMAGE}
    restart: unless-stopped
    environment:
      SQLD_AUTH_JWT_KEY: ${LIBSQL_TOKEN}
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - ./data:/var/lib/sqld

The variable names, container port and data path must match the official release you selected. Treat this block as a layout example, not a substitute for the maintained deployment file. Start only after validating it against the upstream documentation:

docker compose config
docker compose pull
docker compose up -d
docker compose ps

Use the supported client or Turso CLI to create a test database and run a schema migration. Check that the database survives a container recreation before using it from an application.

Step 4, Configuring the reverse proxy

If the server exposes an HTTP API, route a private or protected hostname through Caddy or Nginx and terminate TLS there. Keep the database port bound to localhost unless you have a concrete network design. Add authentication and rate limits according to the server documentation.

Do not confuse a database API with an application API. Never allow arbitrary public clients to write to the database without an application authorization layer. Test certificate renewal and confirm that clients validate the server certificate.

Step 5, First access and initial setup

Create a test database, apply a migration and connect from a small application using the supported libSQL client. Test reads, writes, concurrent connections and a restart. Record the database URL and token in server-side configuration, not in browser code.

Verify that the application handles temporary database unavailability. A single VPS is a single failure domain, so retries and idempotent migrations matter even for a small project.

Maintenance

Back up database files while following the official consistency procedure, and copy backups to storage outside the VPS. Test restoration on a clean server. Monitor disk, write-ahead logs, latency and failed connections.

Upgrade the server only after checking compatibility with the libSQL client and your schema. Keep the exact image digest or binary version used in production. If you need Turso's managed replication or control plane, use the managed service rather than assuming this single node provides the same guarantees.