Draw a small, complete dependency map
A possible layout is an HTTPS entry point, one wiki application, its supported database, an attachment directory and a scheduled worker. DNS and any outgoing email service belong on the map even when supplied elsewhere. No application, mail delivery service or deployment automation is implied by choosing a VPS.
If the application runs in containers, record the persistent locations separately from the container definition. Docker documents that a volume survives an individual container’s removal, while its writable layer does not. That persistence still needs a backup outside the VPS. See Docker’s volume lifecycle. Write the map into the service inventory, including the owner of each dependency.
Budget space before adding more services
Grove’s 2 vCPU, 4 GB memory, 60 GB SSD and 2 TB transfer provide a starting allocation to evaluate for this scenario. The following disk budget is an illustrative planning allowance, not measured consumption or a set of required partitions.
| Use | Planning allowance |
|---|---|
| Operating system, packages and bounded logs | 12 GB |
| Database, page history and search data | 8 GB |
| Member attachments | 18 GB |
| Update and export working space | 8 GB |
| Unallocated margin | 14 GB |
Check the chosen application’s requirements, then observe memory and disk use during an import, ordinary editing and an update. Two vCPU do not establish an editor-count guarantee. Seed may suit a smaller application with verified requirements; Canopy or explicit resource additions become decisions supported by observed demand. Include downloads, exports and backup traffic in the transfer review under the applicable metering terms.
Prove that the notes and attachments belong together
Follow the application’s procedure to capture compatible database, attachment and configuration states. For a PostgreSQL-backed wiki, a logical database export alone does not cover attachments or global database roles. PostgreSQL also cautions that regular production backup planning can require more than pg_dump; choose the method for the actual installation. See the PostgreSQL export scope and limitations.
Rehearse recovery on a separate test destination with outgoing notifications and scheduled deliveries neutralized. Have the second maintainer sign in as an ordinary member, open a known page and attachment, check a restricted page, and confirm an edit can be saved. Record failed checks as work to finish, not a successful recovery. Use the restore drill to capture the result.
Leave a usable route out
Keep a documented export of pages, attachments and the permission model alongside the recovery instructions. Check what the export omits: page history, internal links and account mappings may need separate treatment. Ask the backup maintainer to open the export without relying on the running wiki. The portable export guide helps turn a download into a handover package.
One VPS still concentrates the live service in one place. More resources do not remove that dependency or take over maintenance. Configure the starting plan only after agreeing who handles updates, failed jobs and independent backups; the useful outcome is a service the group can understand and recover.
A catalogue starting point to evaluate
Grove provides 2 vCPU, 4 GB memory, 60 GB SSD and 2 TB monthly transfer at $18.00 USD/month. This is a starting allocation to compare with your application's requirements and measurements, not a promise that a particular collection or audience will fit.
With default options, six months cost $77.76 paid once (28% off $108.00); twelve months cost $108.00 paid once (50% off $216.00). Selected recurring options receive the same discount. Budget independent backup storage, domains and any external mail service separately.
Configure Grove in Iceland ↗Documentation behind this note
Use the documentation for the version you actually run. These examples are planning material, not a record of a test on a Hoszen VPS.