SQLite Setup Guide

Why SQLite?

Unlike MySQL or PostgreSQL, SQLite does not require a separate Docker container. It runs entirely inside the monolithic nLink container, reading from and writing to a single database file on disk. This approach drastically reduces server memory overhead.

Docker Compose Configuration

SQLite is the default database engine out-of-the-box. The only necessary step is ensuring you configure a persistent volume on the nlink service so your database file survives container updates.

services:
  nlink:
    container_name: nlink-workflow
    image: nlinkio/nlink-workflow:v1.2.0
    ports:
      - "80:80"
    restart: always
    volumes:
      # Map the internal storage directory to your host to persist the SQLite file
      - ./nlink_data:/app/storage
    environment:
      - DATABASE_DEFAULT=SQLITE
      - SQLITE_DATABASE=/app/storage/database.sqlite

Configuration Attributes

• File Persistence: ./nlink_data:/app/storage
  (By mapping the data directory, your SQLite database file, e.g., database.sqlite, is kept safely on your physical host machine).
• Auto-provisioning:
  (If the system cannot detect a valid `MYSQL_HOST` or `POSTGRES_HOST`, it will automatically spawn the SQLite file inside its working directory and run migrations on boot).

When to Avoid SQLite

While incredibly fast for reads, SQLite handles heavy concurrent writes less efficiently than dedicated databases. If you plan to run thousands of workflow executions per minute, we highly recommend migrating to PostgreSQL or MySQL.