Skip to content

Storage

wg-access-server supports 4 storage backends.

Backend Persistent Supports HA Use Case
memory Local development
sqlite3 ✔️ Production - single instance deployments
postgres ✔️ ✔️ Production - multi instance deployments
mysql ✔️ Production - single instance deployments

Backends

Memory

This is the default backend if you're running the binary directly and haven't configured another storage backend. Data will be lost between restarts. Handy for development.

SQLite3

This is the default backend if you're running the docker container directly or using docker-compose.

The database file will be written to /data/db.sqlite3 within the container by default.

Sqlite3 is probably the simplest storage backend to get started with because it doesn't require any additional setup to be done. It should work out of the box and should be able to support a large number of users & devices.

Example connection string:

  • Relative path: sqlite3://path/to/db.sqlite3
  • Absolute path: sqlite3:///absolute/path/to/db.sqlite3

PostgreSQL

This backend requires an external Postgres database to be deployed.

Postgres experimentally supports highly-available deployments of wg-access-server and is the recommended storage backend where possible. If you have pgbouncer running in front of PostgreSQL, make sure it is running in "Session pooling" mode, as the more aggressive modes like "Transaction Pooling" break LISTEN/NOTIFY which we rely on.

Example connection string:

  • postgresql://user:password@localhost:5432/database?sslmode=disable

MySQL

This backend requires an external Mysql database to be deployed. Mysql flavours should be compatible. wg-access-server uses this golang driver if you want to check the compatibility of your favorite flavour.

Example connection string:

  • mysql://user:password@localhost:3306/database?ssl-mode=disabled

File (removed)

The file:// backend was deprecated in 0.3.0 and has been removed in 0.4.0

If you'd like to migrate your file:// storage to a supported backend you must use version 0.3.0 and then follow the migration guide below to migrate to a different storage backend.

Note that the migration tool itself doesn't support the file:// backend on versions released after 0.3.0.

Migration Between Backends

You can migrate your registered devices between backends using the wg-access-server migrate <src> <dest> command.

The migrate command was added in v0.3.0 and is provided on a best effort level. As an open source project any community support here is warmly welcomed.

Example: file:// to sqlite3://

If you're using the now deprecated file:// backend you can migrate to sqlite3:// like this:

# after upgrading to place1/wg-access-server:v0.3.0
docker exec -it <container-name> wg-access-server migrate file:///data sqlite3:///data/db.sqlite3

If you need to do the above within a kubernetes deployment substitute docker exec with the equivalent kubectl exec command.

The migrate command is non-destructive but it's always a good idea to take a backup of your data first!

Example: sqlite3:// to postgresql://

First you'll need to make sure your postgres server is up and that you can connect to it from your wg-access-server container/pod/vm.

wg-access-server migrate sqlite3:///data/db.sqlite3 postgresql://user:password@localhost:5432/database?sslmode=disable

Remember to update your wg-access-server config to connect to postgres 😀