Server apps commodified: digital autonomy for the masses

We want to see free and open source software empower more people.

Faced with their dependence on proprietary digital platforms, countries and organisations across the globe have seen a rising interest in achieving digital sovereignty.

Switching to libre services has posed technical barriers in practice however, in particular for non-technical users.

Hosting server software traditionally requires systems administration at the level of the hosted instance, such as a separate Debian VM or container, as traditional computing environments were not designed for reproducibility.¹ Reproducible computing environments such as NixOS reliably centralize such systems administration, but require specialized knowledge to use.

Once applications have been deployed, the presence of application state further makes for switching costs when migrating between hosting providers. The migration process for Mastodon, for example), presumes technical knowledge and spans a dozen steps, as data is spread across different locations.

We propose to address these barriers of systems administration and server migrations by:

1. bridging the cliff between software development and real-world deployment
2. automating the process of getting from a hypervisor to working applications
3. providing a way to easily transfer deployments between hosting providers
4. offering a web front-end to provision and configure selected applications

We still see gaps between the status quo and the achievement of these goals. For each of these fields, we will therefore lay out:

1. desired outcomes
2. challenges we expect implementation to involve
3. prior work
4. envisioned solutions

Automated provisioning

Given a hypervisor, users should be able to easily deploy desired applications on a domain they own.

Challenges to achieve this include:

• Getting to working applications involves the hypervisor, DNS, IP pools, and set-up of data storage and maintenance of relevant secrets (including certificates).
• Data storage and secret management requirements vary across software. Standardization could help.

Prior work includes:

• SelfHostBlocks: NixOS based server management for self-hosting
• SelfPrivacy: automates deployment (and DNS) against the proprietary APIs of hosting platforms DigitalOcean and Hetzner.
• Clan: helps deploy NixOS configurations to devices within one's 'clan'. Of particular interest here is their work on:
  • Vars: manages secrets and computed values.
  • exports: handle states dependencies between nodes.
• RFD: mechanism for adding structured dynamicism to Nix

We want to address this by:

• Automating the provision of relevant hypervisor resources, storage buckets, databases, and e-mail accounts.
• Using OpenTofu to declaratively manage infrastructure state, with state stored in terraform-backend on OpenBao.
• Initially deploying to virtual machines made using hypervisor ProxmoX, but potentially further targeting containers later on.
• Integrating with external registrars / DNS providers using DNS client octoDNS.
• Managing IP address pools using Netbox.
• Implementing extensibility to encourage an ecosystem of deployment methods and applications.

Switching hosting provider

Users should be able to trivially move deployments to a different hosting provider.

Challenges to achieve this include:

• Such migrations involves transfer of relevant state, and potentially further migrating logic. These both differ by application.
• One application might have state spread across databases, a key-value store, queues, block storage, file storage, and secrets.
• Modules in NixOS do not yet offer standardized interfaces across applications to handle back-ups for these.

Prior work to facilitate this includes:

• disnix: handles back-up and restore for full systems, rather than knowing what state is relevant, making it potentially fragile and slow
• SelfHostBlocks' contracts:
  • backup: creating and restoring file backups
  • database backup: creating and restoring database backups

We want to tackle this by:

• Identifying potential gaps among the existing backup contracts to back up state from relevant locations, and implementing solutions for these.
• Automating the process of deploying a new instance, transferring the mentioned state, updating DNS records and running applications' migration scripts.
• Looking into standardizing the handling of such application-specific migration scripts.
• A Vars back-end for OpenBao, so generated secrets may be stored on a central server.

Configuring applications

Although applications should provide sensible default settings, users should be able to visually configure applications if they want. On updates users should be visually guided through new configuration options, and aided to update their configuration if the underlying options changed in backward-incompatible ways.

Challenges to achieve this include:

• While NixOS modules wrap some upstream configuration options, many others they transparently expose, following RFC 42.
• Upstream applications typically document their configuration options, yet often do not expose these in machine-readable schemas.
• Once we have configuration generated by a graphical user interface, handling updates involves tracking option identity, which is non-trivial even when schema update diffs are available.

Prior work includes:

• Nix to JSON Schema converter: helps generate JSON Schemas from Nix option modules.
• Nix function jsonSchemaValidate: offers JSON Schema validation in Nix, though given such a schema we could generate typed Nix modules as well.
• json-schema-diff: extracts additions/removals, so does not track option identity across renames.

We want to address this by:

• Suggesting upstream repositories to add schemas to help migrate options exposed thru settings, or helping implementing these for selected applications.
• Extracting option identity info from e.g. markers like mkRenamedOptionModule.
• In our web interface notifying users who visually configured applications of option changes, suggesting action for options that were added or had their type changed.
• On option changes, showing old vs. new option forms side-by-side.
• For migration of user configuration across configuration option renames on application updates, explicitly track configuration option renames by update, manually confirmed from candidate matches suggested by similarity of option names and metadata.

---

1. While technology like OCI containers has been popularized for offering repeatable workflows, they are not inherently reproducible. ↩︎