A MariaDB primary and two replicas, built by dropping servers in.

The install asks for the root password and does the rest on the way in: root through the socket and the password you gave, no anonymous account, no test database, bound to 127.0.0.1. The version is read from the box before you choose: the distribution's own package by default, so updates come with the operating system, or a series from mariadb.org's repository, long-term support marked. It runs as a job on the server — closing Vigia does not stop it — and when it is in, MariaDB appears on the rail, by name.

A new database is made with a user of its own: every right on that database and none elsewhere. The password is made there and shown once, with the connection string for the app beside it to copy. Vigia keeps no copy of it.

The Explorer is the table the way a database tool shows it. Rows in a grid, edited where they are: click a cell, Enter saves, a new row at the foot. A filter built from the columns, or typed by hand. Any statement run as written — reads are free, a write needs a tick. A query saved as a view.

Columns is the structure: every column with its type, null and default, changed, renamed or dropped from its row; indexes with their size and whether anything uses them; foreign keys. Import reads a CSV or a JSON file on your computer, checks it against the columns, and sends it up as one transaction, so a failed load leaves the table as it was. Export writes JSON, CSV or a real Excel workbook on the server first, as a job you can watch, then brings it to your computer.

The firewall decides who reaches the port; this page is everything after it, read from MariaDB itself and said in words, with the fix on the row. Who may connect: where it listens, how root logs in, anonymous accounts, remote root. Whether connections are encrypted. Whether any password is accepted, "password" included. The features that turn a SQL injection into a file read — LOAD DATA LOCAL, file access, symbolic links — each with what it is for and the button that closes it. A fix that needs a restart says so; one that could lock you out asks first.

Further down the same page: Fail2Ban watching the engine's failed logins, the accounts that are root in all but name, the audit plugin, and certificate logins — an account that is a certificate, not a password, signed by an authority that lives on the box with a key that never leaves it. And the files the engine trusts, with owner and mode, because a secret another user can read is a hole.

A backup is a plan filed on the server: which databases — the ones you tick, or whatever is on the engine that night — each in its own file, with the tables to leave out. When: from cron on the box, the minute picked at random so plans on the same server do not all fire on the hour. What is kept on the box, and where it is pushed: S3 and its houses, Azure, Google Cloud Storage, WebDAV, SFTP or FTP, from the repositories you have described once. Who is mailed when it fails. Vigia can be closed for all of it.

The configuration as rows, not a file: each setting with what it is in a sentence, its value read from the running engine, whether a change is live or needs a restart, and where the value comes from — the engine's default, the distribution's file, or Vigia. Where Vigia would set it differently it says what and why, against the box in front of it: half the RAM for the InnoDB buffer pool on a server that is mostly a database, 1000 IOPS if the disk is an SSD.

And before the rows, what matters on this server today. On the primary built above it said: the buffer pool is 128 MB on a box with 4 GB — the default, sized for a laptop, so every query past the first few megabytes hits the disk. And this box is a primary with two replicas, so a restart from here costs the apps a few seconds, and a switchover first costs them nothing. Every change goes into one file Vigia owns, read last so it wins; the distribution's files are never touched.