Databases

The Data tab lists the databases laraport can reach from the container.

The app’s database

A Laravel container often has the database client (psql, mysql) while the database runs in another container, reachable only on the internal network, as on Dokploy. laraport reads the connection the app is configured with and offers PostgreSQL (app) or MySQL (app):

• It loads only Laravel’s configuration (no service providers run, nothing connects), so it honours config:cache, DB_URL and the real environment over .env.
• The client runs in the app container when it has one, or in the database’s own container on the same server, found by host name. The entry then says run in <service>.
• An (app) entry opens the app’s configured database directly. Other databases on that server are not listed, so you cannot wander into another app’s data by accident. The header shows where you are: via app · host:port/db.

The same works for Redis (app).

Database containers

A container that runs the database server itself gets an entry for it:

• PostgreSQL, when postgres and psql are there;
• MySQL, MariaDB or Percona, when mysqld or mariadbd and a client are there;
• SQLite, when sqlite3 is there: every *.sqlite, *.sqlite3 and *.db file in the app is listed as a database.

Credentials come from the container’s environment: POSTGRES_USER and POSTGRES_PASSWORD; MYSQL_ROOT_PASSWORD, MYSQL_USER and MYSQL_PASSWORD or their MARIADB_* versions. System databases are hidden.

What you can do

• Browse tables and run SQL in the table view, with editing.
• Info and stats: size, version, uptime, largest tables, row counts, cache hit ratio, connections, long-running queries.
• Schema: tables, schemas, views, sequences, functions, columns, foreign keys, routines.
• Indexes: unused and duplicate indexes, index usage, tables without a primary key.
• Maintenance: bloat, locks, replication lag, VACUUM ANALYZE, ANALYZE TABLE, integrity checks.
• Dumps: pg_dump (plain, with inserts, or custom format), mysqldump, sqlite3 .dump, compressed and saved to your downloads folder.
• Restore a dump into a PostgreSQL or MySQL/MariaDB database. See Restoring a dump.

For a desktop client such as TablePlus or DBeaver, open a tunnel to the app’s database.

The SQL input keeps a history per database (↑ ↓), stored in ~/.config/laraport/history.json.

Restoring a dump

Restore a dump, under Backup in the actions of a PostgreSQL or MySQL/MariaDB database, loads a dump from your computer into that database. It accepts:

• PostgreSQL: .sql, .sql.gz, or a pg_dump -Fc .dump;
• MySQL and MariaDB: .sql or .sql.gz.

Turning it on

Restoring is off until you switch on Allow restoring dumps in Settings (s on the home screen), or set allow_restore: true. Until then the action explains how to turn it on.

The window

The restore window shows:

• what happens on an error;
• the exact command it runs;
• PRODUCTION, when this is the production app’s database;
• a field for the dump file on your computer, and one for the database’s name.

It runs only after you type the database’s name. Then ctrl+s, or enter in the name field, starts it.

What happens

The file is streamed to the client in the container over stdin, with progress. Nothing is copied to the server’s disk, and the password goes over stdin as for every other command.

• PostgreSQL restores in one transaction. laraport sends BEGIN before the dump and COMMIT after it, with psql -v ON_ERROR_STOP=1, or runs pg_restore --single-transaction --exit-on-error --no-owner --no-acl for a .dump. An error, a file cut short or a dropped connection leaves the database as it was.
• MySQL and MariaDB run the dump statement by statement and stop at the first error. What ran before the error stays.
• A .sql.gz is checked to be whole before anything is sent.
• The restore counts as done only when the client printed laraport’s end marker, so a stream that stopped early is never reported as restored.

The dump is restored on top of what the database has. To replace the data, restore into an empty database, or use a dump made with --clean.

Restores are recorded in the journal. A read-only server refuses them.

Passwords

Passwords are never put on a command line, where any user on the server could read them with ps. laraport passes them over stdin, and the shell in the container exports them as PGPASSWORD or MYSQL_PWD for that one command.