For the standalone mode, the positioning is clearest when emphasized as libSQL single-node for internal/private use: it has no primary/replica relationships, uses no authentication, and is not exposed to the public internet.

For Primary Node

For Replica Node

Deploy and Host libSQL - Standalone on Railway

libSQL - Standalone is a single-node libSQL deployment that runs independently, without a Primary Node or Replicas. It provides a simple, SQLite-compatible database server for applications running within the same Railway private network. This template is designed for private internal use, with no authentication and no public networking enabled.

About Hosting libSQL - Standalone

Hosting libSQL - Standalone means running a self-contained libSQL database instance that does not participate in replication.

Unlike the Primary and Replica templates, a standalone node does not act as a replication source and does not synchronize its database from other nodes. All database state is stored and managed locally by the standalone instance.

This Railway template is intentionally configured without JWT authentication and without Railway Public Networking. It is designed to be accessed only by trusted services via the Railway Private Network.

Persistent database data is stored at /data/sqld, which must be backed by a Railway Volume to ensure the database persists across service restarts and redeployments.

Common Use Cases

Running a simple, private libSQL database for applications hosted within the same Railway project.
Using libSQL without configuring a Primary and Replica architecture.
Hosting internal development, testing, staging, or lightweight production databases that do not require public access.

Dependencies for libSQL - Standalone Hosting

Official Docker image ghcr.io/tursodatabase/libsql-server:latest.
A persistent Railway Volume mounted at /data/sqld.
Railway Private Networking for communication between the database and application services. ### Implementation Details

Run libSQL in standalone mode:

SQLD_NODE=standalone
SQLD_HTTP_LISTEN_ADDR=0.0.0.0:8080

Use the official Docker image:

ghcr.io/tursodatabase/libsql-server:latest

Mount persistent storage at:

/data/sqld

This template intentionally does not configure SQLD_AUTH_JWT_KEY.

Authentication is not required for the intended deployment model because the database is not exposed via the Railway Public Network. Only trusted services within the Railway private network should connect to the standalone instance.

Networking Model

This template intentionally does not enable the Railway Public Network.

Applications must connect to the standalone database via Railway Private Networking using the service's internal hostname.

A typical deployment topology is:

Application

│

│ Railway Private Networking
▼
libSQL Standalone
│

▼
/data/sqld

No Primary or Replica nodes are involved in this architecture.

The standalone node maintains its database state directly and does not require SQLD_PRIMARY_URL, replication configuration, or a public endpoint.

Since authentication is disabled, this service should only be accessed within the trusted Railway private network. The Public Network should not be enabled unless appropriate authentication and access controls have been configured first.

Why Deploy libSQL - Standalone on Railway?

Railway is a unified platform for deploying your infrastructure stack. Railway hosts your infrastructure so you don't have to deal with configuration, while also allowing you to scale both vertically and horizontally.

By deploying libSQL - Standalone on Railway, you are one step closer to supporting a complete full-stack application with minimal overhead. Host servers, databases, AI agents, and more on Railway. This also ensures a clear distinction between your three templates: Standalone = private single node, Primary = private authoritative node, and Replica = authenticated public node.