Most self-hosted project management tools ship with a database server you have to run alongside the app. PostgreSQL needs vacuuming, backups with pg_dump and major version upgrades. Redis needs memory tuning. You end up maintaining infrastructure instead of managing projects. Eigenfocus skips all of that. Your project data lives in a single SQLite file.

SQLite project management self-hosted means running your project management tool with SQLite as the database instead of a client-server database like PostgreSQL or MySQL. The application reads from and writes to a single file on disk. No separate database process, no connection pooling, no database administration. Backup is copying a file. Migration is moving a file. Inspection is opening it with any SQLite client.

TL;DR: Eigenfocus stores all your project data in one SQLite file. No PostgreSQL, no Redis, no database admin. Back up by copying the file. Migrate by moving it. Inspect it with any SQLite client. It runs in a single Docker container on about 1 GB of RAM.

Why does SQLite project management self-hosted make sense?

SQLite is the most deployed database engine in the world. It runs inside every smartphone, every web browser and most embedded systems. It handles billions of transactions daily across millions of deployments. The engine is not experimental. It is battle-tested.

For project management, the workload fits SQLite well. A busy team generates hundreds of database writes per day. That is nowhere near the concurrency limits where you would need a client-server database. The scenarios where PostgreSQL wins (thousands of concurrent writers, horizontal replication across data centers) don't apply to a team running their own project management tool.

What SQLite gives you in return is operational simplicity. No separate process to monitor. No connection strings to configure. No port to secure. The database is just a file in your data directory.

What does your data actually look like on disk?

When you deploy Eigenfocus with Docker, your project data lands in a mounted volume. Inside that volume, you will find a file called eigenfocus.db. That is everything: projects, issues, custom statuses, custom fields, time entries, labels, comments, user accounts.

Here is what the data directory looks like:

/data/ eigenfocus.db # your entire database eigenfocus.db-wal # write-ahead log (temporary) eigenfocus.db-shm # shared memory file (temporary) storage/ # file uploads and attachments

The -wal and -shm files are part of SQLite's write-ahead logging. They get merged into the main database file automatically. When you back up, you copy eigenfocus.db and the storage/ folder. That is the complete picture.

Compare this to a PostgreSQL-based tool where your data is spread across a data directory with dozens of internal files managed by the database server, and you need pg_dump to get a portable backup.

How to back up your SQLite project management self-hosted data

This is where the single-file approach pays off most directly. Here is the full backup procedure:

Step 1: Copy the database file.

bash cp /data/eigenfocus.db /backups/eigenfocus-$(date +%Y%m%d).db

That is a complete, portable backup of every project, issue, time entry and user in your system.

Step 2: Copy the uploads folder.

bash cp -r /data/storage /backups/storage-$(date +%Y%m%d)

Step 3: There is no step 3.

You can automate this with a simple cron job:

bash 0 2 * * * cp /data/eigenfocus.db /backups/eigenfocus-$(date +\%Y\%m\%d).db && cp -r /data/storage /backups/storage-$(date +\%Y\%m\%d)

That runs at 2 AM daily. No special tools. No database client. No dump format to worry about.

For comparison, backing up a PostgreSQL-based tool looks like this:

Run pg_dump with the correct credentials and connection string
Back up Redis data if the tool uses it
Back up file uploads from a separate storage location
Compress everything
Test the restore (which means creating a fresh database, loading extensions, restoring the dump and verifying integrity)

The SQLite backup is a file copy. The restore is a file copy. There is nothing to get wrong.

See Eigenfocus pricing and editions.

How to inspect your data with the SQLite CLI

One of the practical benefits of SQLite is that you can open the database with standard tools and look around. No need to set up a database client, configure authentication or tunnel into a server.

bash sqlite3 /data/eigenfocus.db

That drops you into an interactive session. From there you can run queries directly:

```sql -- List all projects SELECT id, name, created_at FROM projects;

-- Count issues by project SELECT p.name, COUNT(i.id) as issuecount FROM projects p LEFT JOIN issues i ON i.projectid = p.id GROUP BY p.id;

-- Check total tracked time this month SELECT SUM(durationminutes) as totalminutes FROM timeentries WHERE createdat >= date('now', 'start of month'); ```

You can also use graphical SQLite clients like DB Browser for SQLite, TablePlus or DBeaver. Download the file to your laptop, open it, browse your data. No VPN needed, no port forwarding, no credentials.

This matters for auditing, debugging and reporting. If you need a quick answer that the app's UI doesn't provide, you can query the database directly. Your data is not locked behind an API or a proprietary format.

How to migrate to a new server

Moving Eigenfocus to a different server is straightforward because there is no database server to migrate. Here is the full process:

On the old server:

```bash

Stop the container

Q: Can I query my Eigenfocus data directly?

Yes. Open the database file with the sqlite3 command-line tool or any graphical SQLite client like DB Browser for SQLite or TablePlus. You can run SQL queries against your projects, issues, time entries and any other data. No credentials or special client needed.

Q: How do I back up a SQLite project management database?

Copy the file. Specifically, copy eigenfocus.db and the storage/ folder to your backup location. You can automate this with a cron job. No database dump tools, no special formats. The copied file is a working database that you can open immediately.

docker stop eigenfocus

Copy the data directory

tar -czf eigenfocus-data.tar.gz /data/ ```

On the new server:

```bash

Extract the data

tar -xzf eigenfocus-data.tar.gz -C /

Pull the latest image and start

docker run -d \ -v /data:/data \ -p 3000:3000 \ eigenfocus/eigenfocus:latest ```

Done. Your projects, issues, time entries, custom fields, everything is on the new server. The whole process takes minutes and the only variable is how long the file transfer takes.

With a PostgreSQL-based tool, migration means dumping the database on the old server, transferring the dump, installing PostgreSQL on the new server, creating the database with the right extensions, restoring the dump, then migrating file uploads separately. Each step has its own failure modes.

What about data integrity and durability?

SQLite uses write-ahead logging (WAL mode) by default in Eigenfocus. This means:

Atomic transactions. Writes either complete fully or not at all. No partial writes, no corrupted state.
Crash recovery. If the server loses power mid-write, SQLite recovers automatically from the WAL file on next startup.
ACID compliance. SQLite passes the same ACID guarantees as PostgreSQL for single-writer workloads.

SQLite is not a compromise on reliability. It is used in aviation systems, medical devices and operating systems where data corruption is not acceptable. The testing suite for SQLite has over 100 million test cases. It has more test code than application code by a wide margin.

The trade-off is concurrency. SQLite supports one writer at a time (readers are unlimited). For a project management tool where writes are infrequent and short, this is not a practical limitation.

When would SQLite not be enough?

It is worth being honest about the limits. SQLite is the wrong choice when:

You need hundreds of simultaneous write-heavy connections (think a SaaS platform with thousands of concurrent users writing at the same time)
You need to replicate the database across multiple servers in real-time
You need to run complex analytical queries on terabytes of data while the application serves requests

For a self-hosted project management tool used by your team, none of these apply. You are looking at a handful of concurrent users with a workload of reads and occasional writes. SQLite handles this without any issues.

If you are evaluating infrastructure requirements more broadly, our comparison of what self-hosted project management actually costs to run breaks down the full stack for five different tools.

What else can you do with a single Docker container?

Because Eigenfocus runs as one container with no external dependencies, deployment options open up. You can run it on:

A $5/month VPS from any provider
A spare machine on your office network
A NAS device that supports Docker
A Raspberry Pi (ARM images available)

You don't need to worry about whether the hosting provider supports PostgreSQL 17 or has enough RAM for Elasticsearch. If it runs Docker and has about 1 GB of free memory, it runs Eigenfocus.

This also simplifies updates. Pull the new image, restart the container. SQLite handles schema migrations internally when the application starts. No separate migration scripts, no database version compatibility checks.

For a practical guide on what to do once deployed, see how to set up a project workflow from scratch.

Frequently asked questions

Is SQLite reliable enough for project management data?

Yes. SQLite is the most tested and most deployed database engine in existence. It has over 100 million test cases and is used in safety-critical systems like aviation and medical devices. For a project management workload with a normal team, SQLite is more than adequate. The practical limit is concurrent heavy writes, which project management tools don't generate.

Can I query my Eigenfocus data directly?

Yes. Open the database file with the sqlite3 command-line tool or any graphical SQLite client like DB Browser for SQLite or TablePlus. You can run SQL queries against your projects, issues, time entries and any other data. No credentials or special client needed.

How do I back up a SQLite project management database?

Copy the file. Specifically, copy eigenfocus.db and the storage/ folder to your backup location. You can automate this with a cron job. No database dump tools, no special formats. The copied file is a working database that you can open immediately.

Does Eigenfocus support PostgreSQL as an alternative?

No. Eigenfocus is built specifically for SQLite. This is a deliberate choice, not a limitation. Using SQLite eliminates the need for a database server, reduces RAM requirements to about 1 GB and simplifies backups, migrations and updates. The entire application runs in a single Docker container.

How many users can a SQLite-based project management tool handle?

SQLite supports unlimited concurrent readers. Writes are serialized but each write transaction is typically milliseconds. For project management, this means dozens of active users can work simultaneously without any performance issues. The bottleneck would appear with hundreds of users making heavy concurrent writes, which is far beyond typical project management usage.

Your data should be easy to manage

The point of self-hosting is control. Control over where your data lives, who can access it and how it gets backed up. When the database is a single file, that control is tangible. You can hold your entire project history in a file you can copy, move, inspect and back up with basic command-line tools.

Eigenfocus is source-available, runs in a single Docker container and stores everything in SQLite. No database server to maintain. No infrastructure surprises.

See pricing and get started

Explore how teams use Eigenfocus for self-hosted deployment, as a public-source alternative to closed-source tools or read about data ownership in PM and where your data actually lives.