Skip to content
Serversinc Documentation Operator manual
Serversinc.io Dashboard

Manual reference

Reference

Exact resource relationships, lifecycle states, settings, compatibility rules, defaults, and limits.

Reference pages answer what Serversinc accepts and how it behaves. Use the task guides when you need a procedure; use this section when you need an exact field, state, default, limit, or compatibility rule.

Resource model

Section titled “Resource model”

An organisation owns the customer resources managed by Serversinc.

Organisation
├── Members, credentials, integrations, activity, and billing
├── Servers
│   ├── Applications
│   │   ├── Deployments
│   │   └── Containers
│   ├── Database instances
│   │   ├── Logical databases
│   │   └── Database users and grants
│   ├── Commands and schedules
│   └── Backups and restores
└── Storage providers

An application records desired runtime configuration. A deployment applies that configuration. A container records the observed running instance produced by a deployment.

Database instances have a separate lifecycle from applications, even though their containers run on the same managed servers.

Lifecycle and status reference

Section titled “Lifecycle and status reference”

The full status reference will define states for:

  • Server provisioning, connection, and reporting
  • Applications derived from current container state
  • Containers, including current, retired, and discarded instances
  • Deployment stages, failures, superseded work, and completion
  • Database provisioning and failure
  • Backup creation, batch status, deletion, and locks
  • Restore progress and history
  • Storage-provider verification

A request being accepted does not mean asynchronous work has completed. Clients should follow the created resource until it reaches a terminal status.

Application settings reference

Section titled “Application settings reference”

The application reference will document:

  • Docker image and GitHub source fields
  • Default and per-deployment image tags
  • Private registry credentials
  • Environment variables and secret handling
  • Bind mounts and named volumes
  • Docker networks
  • Port mappings
  • Labels and domain-derived routing labels
  • CPU and memory limits
  • Recreate and rolling strategies
  • Health check enablement and path
  • Stop grace period
  • Deploy hook credentials
  • Which settings require redeployment

Database compatibility reference

Section titled “Database compatibility reference”

The compatibility matrix will list:

  • Supported PostgreSQL, MySQL, and MariaDB versions
  • Default version for each engine
  • Provision, import, backup, and restore support by engine
  • Administrative username conventions
  • Engine and version rules for restores
  • Behaviour that differs between engines

Do not infer compatibility from a container image existing upstream. A version belongs in the matrix only when the complete Serversinc lifecycle supports it.

Backup behaviour reference

Section titled “Backup behaviour reference”

The backup reference will define:

  • Logical database, globals, batch, and Docker volume backup types
  • Full versus selected-database scope
  • Storage-provider requirements
  • Status, failure stage, size, checksum, and storage path
  • Short-lived download URLs
  • Same-server restore and cross-server transfer
  • Target collision and volume overwrite rules
  • Age and count retention
  • Locking and batch pruning
  • Archive and record deletion

Server checks reference

Section titled “Server checks reference”

The server check reference will cover root SSH login, automatic updates, Fail2Ban, time synchronisation, firewall state, and open TCP/UDP ports.

For each check, it will state:

  • What is inspected
  • What good, failing, unknown, and stale mean
  • How often it reports
  • Whether Serversinc can change the setting
  • The effect and risk of enabling remediation

Roles and permissions

Section titled “Roles and permissions”

The permissions reference will compare organisation owner, admin, and member access. It will include resource management, member administration, integrations, credentials, billing, and destructive operations.

The matrix must be verified against API authorisation policies before publication. Interface visibility alone is not proof that an operation is permitted or denied.

Defaults and limits

Section titled “Defaults and limits”

The limits reference will collect verified product constraints, including:

  • Organisation membership cap
  • Backup retention ranges
  • Stop grace default and maximum
  • Scheduled-command frequency options
  • CPU and memory limit behaviour
  • Invitation and token expiry
  • Pagination and log-stream limits

Defaults change. Each value should have one authoritative source and be updated with the feature that owns it.

Security model

Section titled “Security model”

The security reference will explain:

  • Server registration and management authentication
  • Required network paths
  • Organisation isolation
  • Personal access tokens and MCP authentication
  • Secret encryption, masking, write-only fields, and one-time display
  • Command execution privileges
  • Agent update verification
  • Reporting a vulnerability

The management service should be described as part of Serversinc rather than presented as a separate customer product.

API endpoint reference

Section titled “API endpoint reference”

The REST endpoint catalogue should be generated from the current OpenAPI document. It should include request fields, response schemas, examples, authentication requirements, and errors.

Generated does not mean trusted automatically. The schema must be compared with the registered API routes and tested behaviour before every publication.

Read the guides

Section titled “Read the guides”