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.

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.
• Manage the active contract (plan, pricing, limits, custom terms).
• View all invoices and payment history per organization.
• Assign servers to the organization.

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, event logs, and disk usage per server.
• 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.

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. Containers can be linked to services to enable 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, the workspace setup checklist and the workspace network view. 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 Linking Containers link to the booking's components. The sync worker auto-matches them by image reference on the placed server; manual links override and are never touched by the matcher.
• 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, and their vCPU and RAM footprints have to fit the chosen tier. 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, a server over capacity, 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.

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 three 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).
• Workspace network view (edges are derived from category-to-category relations).

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 are the rules that turn into edges on the workspace network view. 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.

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.