Joripo- Home
- Documentation
- Running your own server
- What a Joripo server is made of
Running your own server
What a Joripo server is made of
The engine, the file store that is the record, the database that indexes it, and the choices for where to run them.
Joripo documentation · https://joripo.com/docs/running-your-own-server/what-a-server-is
A Joripo server is three things:
| Part | What it is | If it is lost |
|---|---|---|
| The engine | One application that serves the console, the public website, the web forms, the phones' OpenRosa endpoint and the API, and runs the quality checks. | Install it again; nothing is lost. |
| The file store (the storage root) | Plain files: every form version as uploaded, every submission with its attachments, datasets, reviews. This is the record. | The data is gone. Back it up. |
| The database | PostgreSQL. An index over the file store, plus what only it holds: people and passwords, plans, phones and their keys, quality-finding reviews, field-monitoring set-up, the audit log. | The index can be rebuilt from the files; what only the database holds needs its own backup. |
Because the files are the record, a server can be moved by copying its storage root, and a damaged database can be rebuilt from the tree. The engine re-indexes, at every start, anything on disk the database does not know.
Where to run it
- A Windows computer in your office, reached from the field through an HTTPS tunnel: see A server on a Windows computer and Reaching the server from the field. This is how Joripo's own pilot server has run.
- A Linux server (a small virtual machine is enough for a pilot: 2 processors, 4 GB of memory) running the engine's container, with PostgreSQL and a named tunnel or a reverse proxy in front.
- A managed container host with a mounted volume for the storage root and a managed PostgreSQL.
Whichever you choose, the storage root must be on storage that survives a restart and a redeploy. On a container host, a folder inside the container is wiped on every redeploy (and on some hosts every wake from sleep), taking every form and submission with it; mount a volume and point the storage root at it. The engine logs a loud warning at startup when it detects ephemeral storage in production.
The server's maintainer
Whoever runs the server is its maintainer, with a sign-in of their own to Server administration (/admin), kept outside every organisation. See Server administration.
Before you invite anyone
- Set a long random secret key, and run in production mode, in which the engine refuses to start without one. See Keys and secrets.
- Serve it over https: session cookies are then marked secure, and ODK Collect's password sign-in works only over https.
- Complete first-run setup before the address is public: until an owner exists, whoever reaches the setup page first can claim the server.
- Configure a maintainer, set the data key if the data must be encrypted at rest, and check that backups run.