Reference

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.

Statuses

A request being accepted doesn’t mean the work is done. Follow the resource until it reaches a final status.

The table lists the values the API returns. The dashboard shows them in words, such as Active for active.

Resource	Statuses	Final
Server	provisioning, running_setup, active, failed	active, failed
Deployment	pending, building, in_progress, completed, failed, rolled_back, superseded	completed, failed, rolled_back, superseded
Database	provisioning, running, failed, deprovisioning	running, failed
Backup	pending, running, completed, failed, deleting	completed, failed
Restore	pending, running, completed, failed	completed, failed

An application’s status comes from its current container.

Application settings

The saved application is the desired state. The current container is what’s running. Saving a change doesn’t touch the running container: deploy the application to replace it.

Setting	Default	Allowed values	Shows pending changes
Deploy strategy	recreate	recreate, rolling	No
Health check	On, no path	Any HTTP path, for example /up	Yes
Health check timeout	120 seconds	Fixed	–
Health check interval	3 seconds	Fixed	–
Stop grace period	10 seconds	0–600 seconds	Yes
CPU limit	Unlimited	0.1–128 cores	No
Memory limit	Unlimited	32 MB minimum	No
Environment variables	None	–	Yes
Volumes	None	Bind mount or named volume, read-only optional	Yes
Networks	None	–	Yes
Ports	None	tcp (default) or udp	Yes
Labels	None	–	Yes

With the health check on and no path, Serversinc only checks that the new container stays running. The health check uses the port from the Traefik service label, then the first container port, then port 80.

Every setting in the table needs a deployment to take effect, including the ones that don’t show pending changes.

Database engines

Engine	Versions you can provision	Admin user
PostgreSQL	13, 14, 15, 16, 17, 18	postgres
MySQL	8.0, 8.4	root
MariaDB	10.6, 10.11, 11.4	root

Importing an existing database adopts its container. It doesn’t change the engine or version. Import fails if the engine you pick doesn’t match the server: a MariaDB server imported as MySQL, or the other way round.

Backups

Type	What it contains
database	One logical database. A full backup makes one per database.
globals	PostgreSQL roles and tablespaces. Added to every full PostgreSQL backup.
volume	One Docker volume.

Backups from one run share a batch. Each backup needs a storage provider. A download URL expires after 15 minutes. Deleting a backup removes the archive and its record.

Restore rules

Rule	Detail
Engine	PostgreSQL restores to PostgreSQL only. MySQL and MariaDB restore to each other.
Version	The target can’t have a lower major version than the backup.
Database name	The restore fails if a database with the target name exists. Restores never overwrite a database.
Target instance	If the server has more than one database instance, you must pick one.
Volume name	The restore fails if the volume exists, unless you choose to overwrite it.

Server checks

Server checks cover root SSH login, automatic updates, Fail2Ban, time synchronisation, firewall state, and open TCP/UDP ports. A check can report a healthy, failing, unknown, or stale condition.

Unknown means the agent hasn’t reported enough data to change the check safely. Stale means the last report is too old to trust.

Roles and permissions

Organisations record owner, admin, and member roles. Admin and member do not yet restrict access: every member can manage every resource in the organisation. The owner cannot leave the organisation. The organisation is the access boundary for servers, applications, databases, provider credentials, storage providers, integrations, activity, and billing. Removing a member revokes access to that organisation but does not delete resources they created.

API and MCP clients act with the permissions of the account that created their personal access token. Knowing a resource ID from another organisation does not cross the organisation boundary.

Current limits and defaults

• An organisation can have up to ten members, including the owner.
• An organisation invitation expires after 7 days.
• A server connection command expires after 15 minutes.
• A server is offline after 12 minutes without a heartbeat. Heartbeats are sent every 5 minutes; hardening checks run daily.
• A command times out after two minutes.
• A backup download URL expires after 15 minutes.
• An organisation can have up to 100 custom alerts.
• API tokens can have an optional expiry and are displayed once.
• Scheduled commands support interval, hourly, daily, weekly, and cron schedules.
• CPU and memory values left unlimited do not create an application-level cap.
• Backup retention can use maximum age, maximum count, or both. Locked backups are excluded from pruning.

For provider sizes, engine versions, and resource maximums, the dashboard selectors are the source of truth.

Security model

• Agent. Runs as root with --privileged --pid host and the Docker socket. Organisation access is root access to every server in it.
• Serversinc → agent. Ed25519-signed JWT, audience agent:<server-id>, five-minute expiry, over HTTPS.
• Agent → Serversinc. Per-server secret key over HTTPS.
• Agent updates. The new version checks its own health before it replaces the old one. Images are not signature-verified.
• Organisation isolation. A resource ID from another organisation does not cross the boundary.
• Secrets. Masked, write-only, or shown once depending on the workflow.
• Commands. A confirmation protects against accidental execution; it does not sandbox the command.

See The agent for the full model.

API conventions

The REST API is versioned under https://api.serversinc.io/v1 and uses personal access tokens for authentication. Collection endpoints can paginate and filter. Validation errors identify invalid request fields. Provisioning, deployments, commands, database operations, backups, and restores can continue after the initial response, so API clients must follow the resulting resource status.

The MCP endpoint at https://api.serversinc.io/mcp exposes the same organisation resources through named tools for compatible clients.

Read the guides

• Servers: server connection, provisioning, health, and commands.
• Applications: runtime configuration and deployments.
• Databases and backups: data services, storage, and recovery.
• Automation: REST API, MCP, and deploy triggers.