Requirements of hosting providers and design review
This page lists the requirements that the sources of the project record for hosting providers. For each requirement, it gives the source and the place in the technical design that answers it. It also gives the record of the review of the design.
The specifications of core, of
api and of
panel hold the
requirements that the project wrote for the code. They are not statements of
hosting providers, thus this page does not repeat them. The part traceability
connects them to the design.
Sources
The repository of the code holds no statement that a hosting provider made. The sources below are outside of this repository.
| Source | What it is | Who made the statements | Public |
|---|---|---|---|
| Front-end interview | The summary of an interview of 2026-10-12 that collected requirements for the front end of the panel. The file is meeting-notes/2026-10-12-meeting-summary-front-end-req.md in the meta repository of the project. |
One person of the hosting provider that is a partner of the project | Yes. This page gives a summary only. |
| Architecture notes | The notes architecture-docs/architecture.md and architecture-docs/data-model-requirements.md in the meta repository of the project. These notes are older than the present code. |
The project | Yes. This page gives a summary only. |
| White paper | The white paper of the project, "Server apps commodified: digital autonomy for the masses", in the white-paper repository of the project. |
The project | Yes. This page gives the goals in summary. |
The front-end interview is the only source that records the words of a hosting provider. It has these limits:
- It has the statements of one person of one hosting provider.
- Its subject is the front end of the panel. It does not cover the infrastructure, the metering or the move between hosting providers.
- The person is also a member of the project. The record does not tell which statements the person made as a hosting provider.
- Some statements are ideas for a later version. The tables below mark them.
No source records requirements from other hosting providers.
Requirements from the front-end interview
The column "Answer" tells if the design answers the requirement: "Yes", "In part" or "No". "No" means that the code and the pages of the design show no function for the requirement.
Users and access
| ID | Requirement | Answer | Place in the design |
|---|---|---|---|
| I-1 | The panel is primarily for operators, who are the customers of a hosting provider. | Yes | Scope and the actors. |
| I-2 | The hosting provider is responsible for the authentication. A login with a user name and a password is sufficient. | Yes | Manage users: an operator logs in with the single sign-on of the hosting provider or with a local account. The part access-model has the details. |
| I-3 | The operator makes user accounts and gives the users access to the applications. | Yes | Manage users: each deployment has its own lldap directory and its own Authelia single sign-on. |
| I-4 | An operator makes the first user accounts in less than 30 minutes. | No | The design gives the steps (Manage the users of your deployment). No test measures the time. |
| I-5 | A role with which one operator manages other operators. | Yes | The operators' operator account can manage users' access. |
| I-6 | The hosting provider can see audit logs and the actions of its customers. The interview put this out of its scope. | In part | api records audit events, and the hosting provider selects the store. See Choose the store and the retention of the audit logs and Know which personal data the logs keep. The panel shows to an operator the history of a deployment and of the account (Deploy). |
Use of the panel
| ID | Requirement | Answer | Place in the design |
|---|---|---|---|
| I-7 | The first version operates in a browser on a workstation, preferably Firefox. | Yes | panel is a web application (Containers). The tests of the panel use Firefox (panel/nix/tests.nix). |
| I-8 | The panel obeys the accessibility standards of the W3C. | In part | An automated test with axe-core examines the rules of WCAG 2.1 level A and AA (Accessibility). No person did a manual audit (Publish the accessibility statement). |
| I-9 | The first release has English, Dutch, French and German. | Yes | LANGUAGES in panel/src/panel/settings.py has these four languages. See Translations. |
| I-10 | The panel can show all languages, with text from left to right and from right to left. | No | The panel has no language with text from right to left. |
| I-11 | Later: access from a mobile application. | No | The design has no mobile application. |
| I-12 | The operator changes all settings in the web interface, and then one action deploys the full environment. | Yes | Install applications: the browser sends the full configuration of the deployment to api in one submit, and api puts one build in the queue. |
| I-13 | Idea: before the deploy, the panel shows a list of the changes, and possibly the cost of the deploy. | No | The panel shows no cost of a deploy. The pages of the design describe no list of the changes before a deploy. |
| I-14 | An onboarding sequence: upload a company logo, select the company colors, select the applications. | In part | The operator selects the applications in the form (Install applications). The panel has no onboarding sequence and no setting for a logo or for colors. |
| I-15 | Slow tasks, such as the registration of a domain, start first and continue while the operator makes the other choices. | No | The deploy starts when the operator clicks "Deploy" (Deploy). |
Applications and releases
| ID | Requirement | Answer | Place in the design |
|---|---|---|---|
| I-16 | The operator sees all available applications and can turn each application on or off. | Yes | Install applications: core makes the catalog of the applications, and the form of panel shows it. |
| I-17 | The operator can set limits of use and colors for each application. | In part | The options of an application are in the form (Configure applications, Operator configuration). The design has no general setting for limits of use or for colors. |
| I-18 | Only the project adds an application to the catalog. A hosting provider can turn an application on or off. | In part | The catalog comes from the components of the data model of core (Add an application). The design has no setting with which a hosting provider removes an application from the catalog. |
| I-19 | The panel manages DNS, mail and three to four applications. | Yes | The components of a deployment of an operator list the applications. For DNS, see Assign a domain to a deployment. For mail, see the smtp resource in the system context. |
| I-20 | The project makes one main release each month, on the first day of the month. Fixes can come between releases. | In part | The project makes a release each month, on day 8, and can make one more release in the same month for a fix (SECURITY.md, Make a release). |
| I-21 | The operator sees which changes a release has. | In part | The notes of a release give the titles of its pull requests (Make a release). The panel does not show them. |
Requirements that the project wrote for hosting providers and operators
These statements are from the project. No source records that a hosting provider gave them.
| ID | Requirement | Source | Place in the design |
|---|---|---|---|
| P-1 | An operator selects applications, and the system deploys them to the domain of the operator. | Architecture notes, white paper | Install applications. |
| P-2 | An operator can change the configuration of an application in a web interface. The defaults are sufficient for most operators. | Architecture notes, white paper | Configure applications. |
| P-3 | A hosting provider can give the operator a selection of update policies. | Architecture notes | Update applications: each deployment has the update policy manual, automatic or window. |
| P-4 | When the options of an application change in an update, the configuration of the operator moves to the new options. | White paper | Configure applications: the table of option renames. |
| P-5 | An operator can make accounts for other persons and manage their rights. | Architecture notes | Manage users. |
| P-6 | An operator can move a deployment, with its configuration and its data, to a different hosting provider. | Architecture notes, white paper | Switch an operator to and from a different hosting provider. |
| P-7 | A move is possible when the two hosting providers do not use the same version of the code. | Architecture notes | Switch an operator to and from a different hosting provider: the module source of an operator. |
| P-8 | From a hypervisor, the system makes the resources that an application needs: machines, DNS records, storage, databases, mail and secrets. | White paper | Install applications and the containers. |
Design review
No source records a review of this technical design. The repository of the
code, the meta repository and the white-paper repository hold no list of
reviewers, no date of a review and no result.
A code review of a pull request on the forge is not a review of the design by hosting providers, thus this page does not count it.