Deutsch
An unmanaged VPS is infrastructure that you operate yourself. This page is a readiness checklist for deciding whether your team can own that work consistently. For the broader definitions, cost, control, skills, and service trade-offs, read managed vs unmanaged VPS. Use the checks below to identify an owner, evidence, and a recovery path for each responsibility before placing a production workload on the server.
Virtarix provides self-managed VPS and VDS infrastructure. The customer installs, configures, secures, updates, monitors, and operates the software on the service. That boundary makes operational readiness more important than confidence alone.
How to use this readiness checklist
For each item, write down who owns it, when it is performed, where the runbook lives, and what proves it works. A tool being installed is not evidence that the process is ready. Prefer a tested command, alert, restore, rollback, or handover record. If an essential responsibility has no owner or test, treat it as a gap to close before production.
12-point unmanaged VPS readiness checklist
1. SSH and Linux administration
You can create and remove users, manage SSH keys, use sudo, inspect services and logs, correct file ownership and permissions, and recover from a failed configuration. Document an emergency-access method and verify that a second authorised person can follow it without sharing credentials.
2. Operating-system and application patching
Maintain an inventory of the operating system, repositories, runtimes, services, and applications you must update. Define a patch cadence, a process for urgent security updates, a maintenance window, reboot checks, and a rollback method. Test updates away from production when the workload makes that necessary.
3. Firewalling and network exposure
List every required inbound and outbound connection, then deny traffic that the workload does not need. You should be able to inspect listening services, manage the host firewall, restrict administrative access, and verify exposure from outside the server. Firewall and network configuration remain customer responsibilities on an unmanaged VPS.
4. Backups and restore testing
Every Virtarix VPS and VDS includes one backup and one snapshot, but those recovery points do not replace customer-owned copies or an independent recovery plan. Define what data and configuration must be copied, where independent copies live, who can access them, and how often a restore is tested. Record the last successful restore and the recovery objective it proved.
5. Monitoring and alerting
Monitor availability, CPU, memory, storage, network behaviour, application health, critical logs, and certificate or job failures that matter to the workload. Alerts need an owner, a delivery path, a severity rule, and a response action. Test that a simulated failure reaches the responsible person and produces enough context to investigate.
6. Incident response
Keep a short incident runbook covering detection, triage, containment, communication, recovery, evidence preservation, and follow-up. Define when to rebuild instead of repair and how to contact the infrastructure provider for an infrastructure issue without assuming the provider manages the application. Run at least one tabletop or controlled failure exercise.
7. Application deployment and rollback
Use a repeatable deployment process that identifies the artefact, configuration, dependencies, service account, database changes, health check, and rollback point. Another operator should be able to deploy or revert the application from the runbook. Avoid production-only manual steps that cannot be reproduced or audited.
8. DNS and TLS ownership
Record the authoritative DNS provider, required records, change approvals, TTL considerations, and rollback steps. Document how TLS certificates are issued, renewed, and checked. Alert before expiry, and verify renewal plus service reload behaviour before relying on automation.
9. Database ownership
If the workload uses a database, assign responsibility for access control, updates, schema migrations, capacity, backups, consistency checks, tuning, and recovery. Test application and database rollback together when a release changes data. A server snapshot alone is not a database recovery procedure.
10. Secrets and privileged access
Know where passwords, API tokens, SSH keys, encryption keys, and application secrets are stored. Restrict access, prevent secrets from entering repositories or logs, define rotation and revocation, and record who can approve privileged access. Test that an exposed or departed-user credential can be replaced without losing control of the service.
11. Offboarding and ownership transfer
Have a process to revoke accounts, keys, tokens, dashboards, alert destinations, and third-party integrations when a person or supplier leaves. Transfer runbooks, recovery access, billing ownership, domain access, and independent backups to the next owner. Confirm that no critical process depends on one person's device or memory.
12. Time and on-call capacity
Estimate the recurring time for updates, reviews, restore tests, certificate checks, capacity work, and documentation, then account for unplanned incidents. Name a primary and backup operator and define after-hours expectations. If nobody can respond within the workload's required window, the team is not ready to own that production service without assistance.
Customer-managed application stacks
An unmanaged VPS can fit software that the customer installs, patches, secures, monitors, and operates. Examples include websites, APIs, application workers, databases, and customer-managed containers. The fit depends on whether the team can own the complete operating lifecycle described above, not simply whether the software can be installed.
Choose your outcome
Ready for unmanaged
Choose this outcome when every critical responsibility has a named owner, a usable runbook, and current test evidence. Recovery, incident response, privileged access, and on-call coverage must work without depending on one unavailable person.
Ready with a runbook/assistance plan
Choose this outcome when the team can operate the service but specific gaps still need documented assistance, training, tooling, or a specialist. Name the gap, owner, source of assistance, and completion condition before production. Assistance does not transfer responsibilities that the service contract leaves with the customer.
Use managed hosting for now
Choose this outcome when the team cannot yet own a critical area such as patching, firewalling, backups and restores, monitoring, incident response, database recovery, secrets, or on-call coverage. Select a managed service whose written scope explicitly covers the responsibilities you need, then reassess unmanaged hosting when the missing capability and evidence exist.
The decision is about operational ownership, not a score or a preference for one hosting model. Revisit the checklist when the workload, team, dependencies, or recovery requirements change.
