Admin Guide

Platform Roles

Platform roles determine who can access the administration panel and what they can do:

Dashboard

The admin dashboard displays key performance indicators at a glance: total organizations, monthly recurring revenue (MRR), active services, open orders, server health, and recent activity. Top customers are ranked by revenue.

Every list tile shows at most ten rows and ends on the same foot: the way to the full page and how many rows stayed behind on it. What a tile states in its headline — the fleet's condition, the sum of the open invoices, the number of alerts — is the tally of everything, not of the rows on screen. An organization still under review is an applicant and not a customer: it is counted by neither the customer tile nor the MRR beside it, and it appears on no plan until it is approved.

Managing Organizations

The organizations overview lists all customer organizations with member counts, active services, and contract status. Click an organization to see its details: contract, workspaces, services, invoices, and members.

• View and edit organization details and billing address.
• See the contract address from onboarding, marked as picked from the address search or entered manually.
• Manage the active contract (plan, pricing, limits, custom terms).
• View all invoices and payment history per organization.
• Assign servers to the organization.

Approval & Rejection

An organization a customer creates arrives under review and gives nothing up until it is decided: no booking, no invitation, no change to its own master data. Owners and operators decide; the review shows the plan that was applied for beside the company details.

The approval is what provisions the organization. In one transaction it writes the contract on the plan applied for, the first workspace and the first invoices for the running billing period, and the applicant is mailed afterwards. An approval that failed halfway wrote nothing and is simply repeated; a plan withdrawn in the meantime stops it and says so.

A rejection records the decision, ends the application, withdraws every open invitation and retires the invite links. Where the organization had already been approved, its contract and every invoice that is neither paid nor cancelled are cancelled with it. The rows stay for a later complaint, nothing is queued to erase them, and the applicant gets one email. A rejected organization cannot be approved afterwards — the applicant may apply again.

Members

The members section shows all users across the platform. You can search by name or email, filter by platform role, and view member details including their organization memberships and activity history.

Servers

Servers represent the physical or virtual infrastructure running customer services. Servers can have parent-child relationships (e.g. a Proxmox host with VMs). Each server tracks live metrics: CPU, memory, disk, and network usage.

• Create servers with provider, location, IP, and specs.
• Assign servers to organizations and workspaces.
• View real-time metrics and disk usage per server.
• Read the server logbook: everything the customer is told about the machine and everything only we do to it, filtered by who caused it or how serious it is. Entries marked internal are never shown to the customer.
• Write a logbook entry by hand and choose whether the customer sees it. Entries cannot be edited, only removed.
• Track sync status and connection health.

Connections

Connections link your servers to external infrastructure providers for automatic metric synchronization and container discovery.

After creating a connection, use the "Test" button to verify API access. Then add datasources to link individual servers to the connection for metric synchronization.

Disks

The server detail page lists every disk the platform holds for one machine: its mount point, device and file system, its last figures, when they were last refreshed, and which connection reports it.

A disk belongs to its server, not to the source that found it. When a source stops reporting a mount point, the disk keeps its history and is marked as orphaned instead of being deleted, so pointing a server at a new datasource never destroys what was measured before.

An orphaned disk has two verbs, both on its own row and both for platform staff only. Merging joins its history to a disk a source still reports on the same machine: the measurements continue under the target and the orphan is gone. Dropping takes the disk and its measurements away. A merge cannot be undone, so the confirmation names both mount points and the period being moved before you commit to it. Both are written to the platform side of the server logbook under your name.

This list is the only place an orphan appears. The per-disk chart above it draws the disks a source still reports and nothing else, so an orphan never reaches a customer surface and a customer has no verb for one. Where storage was not measured at all, the chart and the metrics above it say so in words rather than leaving the figure out; why it was not measured stays in the datasource sync log.

Containers

Docker containers running on servers are automatically discovered during sync. Each container tracks its status (running, stopped, paused, exited), CPU, memory, disk, and network usage. Each container is assigned to the service component it serves, which is what gives lifecycle control and health monitoring.

Service Catalog

The service catalog defines what customers can book. Each catalog item has a name, description, setup time, an icon, its components (the containers the software consists of, with nominal vCPU/RAM/storage footprints), and its management tiers (paid responsibility levels with coverage lines; tier 0 "Self-managed" is implicit and free). Items can be toggled between active, public, and bookable; non-public items are customer-specific and only assignable by platform admins.

Every catalog item must also be linked to a service category (Communication, Productivity, Security, and so on). The category drives the customer-facing catalog filter and the workspace setup checklist. Save is blocked until a category is selected.

Service Instances

Service bookings are individual deployments booked by customers. Each booking is linked to a workspace and a catalog item, carries a management-tier snapshot, and places its components on one workspace server (the vCPU/RAM footprints count against the server's capacity; storage is informational and grows via server add-ons). You can manage credentials, technical notes, and logbook entries per service.

• Container assignment The service page lists the booking's components in three columns: the component with its booked vCPU and RAM, the container that serves it with its uptime, and the state the component is in. A component no container serves is marked in place of the container name. Open a row for the server the component sits on and, under it, either the container that serves it (the image comparison, its usage, and where the assignment came from and when) or the free containers of that server, grouped by how closely their image matches the booked one and searchable by container or image name, with what the next sync would do. Where the server booking carries no machine yet, that place names the state the booking is in instead of listing containers. The sync matches by image reference every minute and only ever fills a component that carries no assignment.
• Finding the gaps The services list filters on bookings with a component no container serves, so a deployment stuck on "being set up" is found without opening every service. A component's server can be corrected only while no container serves it.
• Actions Start, stop, and restart the linked containers of a service.
• Logbook Add customer-visible or internal notes about status changes and maintenance.

Status & Monitoring

Each service has a status that reflects its operational state. The status is updated automatically by the server sync worker from the health of the containers linked to its components, or manually by an admin.

The uptime chart on the service detail page shows daily availability over the last 7, 14, or 30 days. Live container health is displayed alongside the status badge.

Package Catalog

Under Administration > Packages you build the blueprint. Every package needs at least one server; components of a service must be placed on one of the package's own servers. The price bar shows the list price of all positions, the package price you enter and the resulting saving, and it recalculates while you edit.

Saving is blocked while the blueprint has an issue: a missing catalog row, a service tier that no longer exists, an unplaced component, or a required dedicated IP without a server that has one. The same evaluation runs again on the server, so the totals are never taken from the browser.

Placing more vCPU and RAM on a server than its tier carries saves anyway. The preview marks the capacity bars and lists the finding below the issues, in its own colour, because a package can be built for a customer who will not run everything at the same time.

Versions

Every change to the blueprint creates a new version; name, description and visibility do not. Before saving, the diff dialog shows what changes against the current version. Existing assignments keep the version they were bound to, so a price change never reaches a running customer package.

The detail page lists the version history with the booking count per version, and a package that is still assigned somewhere cannot be deleted.

Assigning a Package

Packages are assigned from the customer's organization page, never by the customer. The dialog previews everything before anything is written: the positions with their prices, whether the servers fit the workspace limit, whether a new workspace is still allowed by the plan, and which data processing annexes the customer has not consented to yet.

• Target Bind the package to an existing workspace or let the dialog create a new one for it.
• Provisioning The bookings are created directly, without setup orders: the customer never ordered these services, so their order board and their order allowance stay untouched. Link the VMs as usual on the server booking.
• Billing A prorated invoice covers the remaining days of the current period. From the next billing day the positions ride the regular monthly invoice.

Conditions & Cancellation

The package price is not a separate invoice line. Each position is billed at its list price and gets the difference back as a visible credit line, grouped per package and closed with the package total. Package positions do not take part in the inclusions of the plan while the package runs; once it expires they do again, without a single row being touched.

Single positions of a package cannot be cancelled, neither by the customer nor from the admin panel: the tier and the price of a position are fixed by the package. Only the package as a whole ends, at the end of the paid period and at the earliest at the end of the minimum term. The customer decides which positions end with it; everything else runs on at list price. Until the effective date, the cancellation can be revoked from the package card on both sides.

Service Categories

A service category groups offerings under a shared label (Communication, Productivity, Security, Backup, and so on). Each category has a slug, name, description, icon, color hint and display order. The same category is used in two places:

• Catalog filter on the customer side (every catalog item is linked to exactly one category).
• Workspace setup checklist (each checklist item belongs to exactly one category; status is derived from the workspace's services in that category).

Manage categories at /administration/categories. The detail page shows which catalog items, checklists and relations reference the category, so you can see what depends on it before changing anything. Categories cannot be deleted while catalog items still reference them.

Category Relations

Category relations describe how one service category connects to another. Each relation has a source category, a target category (or a wildcard meaning "every other category"), a type, a label and a default state.

Default state decides how the edge is drawn for customers without manual intervention:

• Active The relation is drawn solid. Use this when the relationship is automatically true whenever both sides exist (for example, a backup always protects the services in its workspace).
• Available The relation is drawn faded. Use this when the relationship is possible but not automatic (for example, an automation could integrate with a shop, but only if explicitly wired up).

Manage the matrix at /administration/categories/relations.

Workspace Purposes

A workspace purpose describes what a customer's workspace is for: Office, Online Shop, Accounting, Agency, Freelancer, IT team, or General. Customers pick a purpose when creating a workspace; the purpose decides which checklists their workspace will see beyond the default ones.

Manage purposes at /administration/checklists/purposes. Each purpose has a slug, name, description and icon. The pivot column shows which checklists are attached to it; you can attach or detach checklists from the checklist editor.

Checklists & Items

A checklist is a reusable bundle of items that together describe what a workspace typically needs. A checklist can be marked as default (it applies to every workspace) or attached to one or more purposes via a multi-select.

• Default checklists The basic setup applies to every workspace, regardless of purpose. Use this for items that everybody needs (e.g. business email, cloud storage).
• Purpose-linked checklists Add purpose-specific items on top. For example, the "E-Commerce essentials" checklist is linked to the Online Shop purpose and only appears for those workspaces.
• Checklist items Each item has a slug, name, description and one category. The category is mandatory; the customer-side status is derived from the workspace's services in that category.

Manage checklists at /administration/checklists. Adding or renaming an item takes effect immediately for all workspaces that see the checklist - there is no versioning. Removing or recategorising an item changes the next checklist render for affected workspaces.

Contracts & Plans

Each organization has one active contract that defines their plan, monthly base fee, included resources (users, storage, support hours), and hourly rate for billable orders. Plan templates define the standard tiers (Free, Basis, Premium) with configurable limits.

• Plan Transitions Schedule a plan change for the next billing day. The old contract is replaced and a new invoice is generated on the new plan.
• Custom Terms Override template values with individual pricing for specific customers.

Invoicing

Invoices are generated automatically on each organization's billing day. They include the base fee, active services (prepayment), billable orders from the previous period (arrears), and storage overages. Tax is calculated at 19% (German VAT).

You can also create invoices manually for one-off charges. The system validates that amounts are computed server-side from quantity and unit price.

An invoice that is open or overdue can be mailed again from its own page: Send by email in the action menu. Owners and operators see it. A draft has nothing to send yet, a cancelled invoice is not chased any more, and a paid one is not offered it, because the mail announces an invoice to pay. The confirmation names the billing recipients it would go to before you commit.

This builds a new mail with today's figures and a freshly attached PDF, in a delivery of its own. It is not a repeat of the mail the customer already has, and it leaves what is already in the communication log untouched. The customer's bell rings only for the first mail an invoice ever gets, so sending again does not announce the same invoice a second time.

Payments

Payments can be recorded against invoices with various methods (Stripe, bank transfer, manual). When the total payments match or exceed the invoice gross amount, the invoice is automatically marked as paid.

Billing Cycle

The billing cycle is tied to the organization's creation date. If created on the 7th, billing runs on the 7th of each month. The daily billing job runs at 06:00 UTC and processes all organizations whose billing day matches. A catch-up mechanism handles missed billing days.

Orders & Processes

The admin orders view shows all orders across all organizations. You can create orders, assign them to services, link processes, and track time. Process templates can be managed under Templates for reuse across organizations.

Every submitted standard order needs a classification before it can be completed. It decides who pays and drives the quote flow:

Orders linked to a service run through the service's queue: one active order at a time, further ones wait in the Queued status and move up automatically. Setting an order to completed or cancelled opens the next waiting order.

Alerts & Feedback

Alerts reported by customers appear in the alerts section with priority levels and preset labels (Service unavailable, Login issues, etc.). You can create support orders from alerts for structured follow-up. User feedback is collected separately and can be marked as reviewed.

Background Jobs

The platform runs scheduled background jobs via BullMQ with Redis. The Bull Board dashboard at /administration/bull-board shows the status, history, and metrics of all jobs. Failed jobs are retried up to 3 times with exponential backoff.

Communication Log

The communication log under Administration lists every outgoing mail as one row per delivery chain: all attempts at the same mail to the same recipient, carried by the latest one. Opening a row shows the recipient, the subject, the template, every attempt with its outcome, and the provider's answer word for word with a failure class saying whether trying again can help.

Owners and operators can send a mail again from the sheet. The resend goes to the recipient the chain has always had, with the content it carried when it was first sent; an invoice, quote, reminder or receipt PDF is rebuilt from its record. There is no address field: a wrong address is corrected on the organization and the mail is triggered afresh from there. Developers see the whole log but no send control.

• The confirmation dialog quotes the provider's last answer, so the decision is made with the failure in front of you.
• A transient or unrecognised failure is retried by the platform itself: five attempts in all, waiting 5 minutes, 30 minutes, 2 hours and 6 hours between them. The sheet says when the next retry is due, or that the platform has given up and the chain is waiting for you. A permanent failure, auth mail and anything that failed before retries existed is never retried automatically.
• A resend appears as a further attempt on the same chain, never as a new row.
• Resend, or send again from the record? Resend from the log when the mail was right and simply did not arrive: the same content to the same address, added to the chain that is already there. Send again from the invoice when the mail has to be made anew, because nothing was kept to render it from, because the figures have moved on, or because the billing recipients have. That is a new mail in a delivery of its own, and it leaves the failed one standing as the record of what happened. Only invoices offer it; a quote, receipt or reminder is sent again from the log.
• The Type filter narrows the log to invoices, quotes, payments, reminders, receipts, channel verification mail, member mail, content notices or suspensions; channel verification is auth mail, and choosing it shows it without the Auth mail toggle. Beside it the organization filter narrows the log to one customer, so the invitation that went out for them can be found without knowing the recipient. The reference opens the invoice or quote a mail is about; for an organization's contact or billing address it opens the organization, and a member's personal address has no page here.
• Every mail the platform sends is in the log, sign-in links, verification and password reset mail included. Each carries the category of its template: business, notification, auth or system. Auth mail is hidden by default so it does not drown out the rest; the Auth mail toggle in the filter bar shows it, and choosing Auth in the category filter shows only it. Auth mail is logged and nothing more: no content is kept, and it is never retried or resent.
• A resend is refused, with the reason shown, while the last attempt is still in flight, for auth mail and the test mail, when nothing was kept to render the mail from, and when the record no longer supports it: a cancelled or deleted invoice, a paid invoice behind a reminder, a withdrawn or expired quote, a deleted organization. An invitation is refused for a reason of its own: its link is single-use and is not kept, so the member is invited again from the organization's member list.
• How long a mail stays in the log follows what it is evidence of. An invoice, receipt, quote or reminder, and every mail about one, is kept for 6 years from the end of the year it was sent: it is a commercial letter, which § 257 HGB and § 147 AO require to be kept that long, and a reminder is one in its own right. Other notification, legal and system mail is kept for 4 years from the end of the year, the regular limitation period of §§ 195 and 199 BGB. Auth mail, which carries only an address and a time, is removed after 90 days: under the storage limitation of Art. 5(1)(e) GDPR it stays no longer than security diagnosis needs it. A chain is removed whole once its last attempt is that old. The content a mail was rendered from is cleared after 30 days, the entry itself staying, and from then on the chain can no longer be sent from the log.
• Each attempt records which version of the platform rendered the mail, shown in the sheet, so the wording a customer received can be reconstructed if it is ever disputed.