Flaem operator panel

Flaem is the system a hosting company sells and runs game servers, VPSs, websites, domains and mail on. This panel is its command centre: from here the operator sets up the installation, onboards nodes, defines plans and prices, bills clients and resellers, and runs the network and the team. All of it sits on the operator's own machines, so the panel cannot assume someone else is watching the infrastructure.

We built it around the question an operator asks every morning: what needs a human today? The dashboard, queues, alerts and approvals answer it on one screen, and the rest of the panel exists to keep that list as short as possible.

A fresh installation is a licence, not a store. Before the first client buys anything, someone has to enter the seller details, switch on payment gateways, connect KSeF, pick a domain registrar, add IP address pools, onboard nodes and publish the first offer. Each of those steps is easy to miss, and a missed one only shows up when a client gets stuck in the cart.

The setup checklist walks that whole road in the order an operator actually works, and it ends not at the nodes but at a store with something to buy. The panel reads the state of every step from the configuration itself each time it is opened, so a step cannot be ticked without doing it, and a step someone later undid goes back on the list. The only thing the panel stores is the decision "not needed": a step the installation does not need stays in its place with one sentence of explanation instead of disappearing.

Second on the list is a mandatory second login factor for the team. That is deliberate: who may run the installation at all has to be settled before anyone wires money into it.

The dashboard shows the numbers an operator checks every day anyway: MRR, sales, active clients and active services, each with its change against the previous period. Next to them sit a revenue chart, live nodes with CPU and memory load, and the list of matters waiting for a human: a paid service with no free address, a backup that failed overnight, an invoice rejected by KSeF, urgent tickets and refunds waiting for a second signature.

That list is the heart of the screen. Every entry says what it concerns and how long it has been waiting, and a click leads straight to the place where it can be dealt with. Whoever is on call does not dig through ten tabs looking for trouble, because trouble lines up in a queue by itself.

A node is onboarded with a command the panel prepares itself. From then on its telemetry, updates, network and backups live in the panel: every core, disk and network card, pending system packages, security fixes and whether a reboot is needed. Every update package passes a signature check, and if a new agent version does not come up, the node rolls back to the previous one on its own. A change to a node's network has a set time to confirm it can still reach the central server and reverts itself without that confirmation, so an operator cannot lock themselves out of a remote machine with one bad save.

When a node stops answering, nothing moves by itself in the middle of the night. A human makes the decision and the system does the rest.

An invoice is issued the moment a payment lands, and its FA(3) file goes to KSeF in the background. A purchase never waits for KSeF, so an outage on the tax system's side never blocks a sale or a renewal. The invoice screen shows every document's path: issued, sent, accepted with a KSeF number, or rejected with a reason. A rejected one lands on the list of matters for a human, and the fix goes out as a correction through the same queue.

Alongside sit numbering series, VAT rates, the OSS procedure for clients in other EU countries, NBP exchange rates on foreign-currency invoices and a tax register. When a month closes, the operator downloads one package for the accountant: revenue, MRR, refunds, reseller commissions, node profitability and liabilities held in client wallets, together with the JPK file.

An operator with their own network sells not only servers but also transit, IP addresses and BGP sessions. The panel holds AS numbers, prefixes with their route objects in RIPE and their RPKI validity, BGP sessions with an owner, a route filter and a history, and attack protection at providers such as Path.net and OVH. A route that is invalid in RPKI is rejected before it is saved, and every address has a state: free, assigned to a service, assigned to an account or leased. The same address never ends up on two machines.

Roles are built from single permissions, down to one action, so support can read invoices without issuing refunds. A role can also be narrowed to chosen nodes or to one reseller's brand. The backend guards that line on every request, not a hidden button in the interface: a panel route with no permission on record is refused instead of standing open.

The middle case matters most. A role narrowed to one node does not cover an action that concerns no node at all, otherwise the keeper of a single machine could change settings for the whole installation. Actions that cannot be undone, such as deleting a service, deleting a node and moving money, turn into a request for a second authorised person, and the approval runs the stored action straight away. Every staff action lands in the audit log: who, what, when, from where and on whom.

Game hosting attracts stolen cards, because a service is ready in minutes and a chargeback arrives weeks later. The panel scores every order and every sign-up before anything is started: it accepts it, holds it for review with delivery paused, or rejects it with a case number. Separately it watches what client machines do to others: miners, spam, scanning and outgoing attacks, with a response that escalates step by step and can always be reversed.

Operators move to Flaem from their existing billing system, game panel, VPS panel or web hosting panel. An import starts with a dry run, and nothing is created in the new system until the operator approves the report. Moved services work from the first moment, but they are not billed or suspended until the operator prices them, so during the switch nobody gets an invoice or a block by accident.

The operator runs hosting from one panel: from an empty installation, through the first sale, to the daily work with nodes, money and people. There is no jumping between billing, a game panel and a terminal, because the order, the machine, the invoice and the ticket live in one installation and know about each other.

The most important part happens in the background. Risky changes have a prepared way back, irreversible ones wait for a second person, and everything that needs attention lines up in one queue instead of getting lost in an inbox. That is what lets a small team run the installation, with every decision leaving a trail that can be followed back.