Self-Host Metabase with Greffon
Metabase points at your data and turns it into dashboards and questions. When that data is your business, the box it runs on should be one you own. Here is the honest setup.
Metabase is open-source business intelligence: you point it at a database, ask questions in a query builder or in SQL, and turn the answers into dashboards your team can read. The catch with hosted BI is that your queries, and often a read path into your production data, run through someone else's account. Self-hosting keeps both on a machine you own. Greffon takes the reverse proxy and certificate work off your plate so you can get to the dashboards instead of the plumbing.
Why own your BI
Metabase sits close to your most sensitive data. To chart anything it needs a connection to the database behind it, which often means read access to the same store your application runs on. Where Metabase lives, and who can reach it, is therefore a real security decision, not a convenience one. Running it on your own greffer keeps that connection inside infrastructure you control rather than handing a credential to a hosted tier.
Metabase ships under an open-source core with paid Pro and Enterprise editions layered on top. The catalog greffon runs the open-source edition, which covers questions, dashboards, and the common database drivers. If you later need the paid features (advanced permissions, embedding entitlements), that is a licensing decision you make deliberately, not a default you back into.
Graft it from the catalog
On a greffer you do not hand-write a compose file or wire a reverse proxy. Pick Metabase from the catalog and graft it onto your greffer. Greffon issues the certificate and routes the app, so it comes up reachable over HTTPS. On first load Metabase walks you through creating the admin account and connecting your first database from inside the web UI.
The encryption key matters
Metabase encrypts the database connection credentials it stores at rest with an encryption secret key. The greffon generates that key for you when the instance is created and holds it as a write-only secret. The one rule worth committing to memory: do not change it after the fact. Rotate or lose that key and Metabase can no longer decrypt the saved connection details, which means re-entering every data source by hand.
Give it enough memory
Metabase runs on the JVM, and that is the tradeoff to plan for. It is comfortable rather than tiny: a real instance wants on the order of a couple of gigabytes of RAM to stay responsive, more if several people are loading dashboards or you run heavier queries. This is the one app in a small catalog where a 1 GB box will feel it. Size the greffer accordingly, and if a dashboard feels slow, memory pressure is the first thing to check before you blame the queries.
Reach it from anywhere
Metabase is a plain HTTP app, which keeps external access simple. On the same network as your greffer it works the moment it starts. To reach it from elsewhere you have two honest options.
The simplest is tunnel mode: a greffer connects outbound to the manager's tunnel and serves its apps without opening a single inbound port, which is the answer for a box behind NAT or CGNAT with no public IP. If you would rather expose the greffer directly, port forwarding plus dynamic DNS still works. Either way the app stays reachable over HTTPS, and because Metabase speaks HTTP the tunnel carries it without caveats.
Back up the app database
Metabase keeps its own state (your questions, dashboards, users, and the encrypted data-source credentials) in an application database. That state is what you cannot recreate by hand, so it is what you back up. Greffon handles TLS and routing today, and native one-click backups are coming in M2. Until then, bring your own backup tool (restic or borgbackup are the usual choices), back up the Metabase data on a schedule, and store a copy off the greffer along with the encryption key.
Note the distinction: backing up Metabase protects your BI setup, not the source data it charts. The databases Metabase connects to need their own backups. Losing the Metabase state costs you dashboards you can rebuild; losing a source database is a separate, larger problem you should already be guarding against.
