Roles, members, and access rules in the running self-hosted web app
Scope
What this area changes in the data flow.
Self-hosting moves control and responsibility to the operator. Open Inventory provides Compose files, migrations, a health endpoint, PostgreSQL and persistent upload storage as a documented base. Backups, restore tests, TLS, network exposure and updates remain operational tasks.
Result 01
Run and inspect the web app, API and iOS client on infrastructure you control
Result 02
Define roles, granular permissions and content-dependent access rules
Result 03
Manage the database, files, secrets, backups and optional providers explicitly
Included implementation
Individual capabilities and constraints.
These components are part of the MIT-licensed project. Optional providers are identified where they take part in a workflow.
01
Roles and conditional rules
Manage local accounts, custom roles, granular permissions and content-dependent access rules. Auth0 can be added as an optional identity provider.
02
Docker Compose and PostgreSQL
Containers, migrations, a health endpoint and persistent volumes for PostgreSQL and local uploads are checked in. Configuration and secrets remain deployment concerns.
03
Selectable file storage
Store uploads in a persistent local volume by default or configure Openinary. Database and file storage must be backed up as one recoverable dataset.
04
MIT-licensed source
The web app, API and native iOS client are published in one repository. The MIT license permits inspection, modification, operation and redistribution.
Sequence
An open stack still requires operating decisions
Starting Compose is the first step. Identity, persistence, recovery and controlled upgrades are required for a durable service.
01
Start the instance
Use the checked-in Docker Compose services, PostgreSQL, migrations and health endpoint as the baseline.
02
Restrict access
Configure accounts, roles and rules, then decide whether the instance is private or exposed through a hardened reverse proxy.
03
Back up all persistent data
Back up PostgreSQL and the selected file store together, and verify restoration regularly.
04
Apply updates deliberately
Review repository changes, update images and migrations in a controlled sequence, and monitor the health endpoint.
Worked example
Concrete records, states and decisions.
The values are mock data, but the workflow and state changes correspond to operations implemented by Open Inventory.
concrete example
Example · Self-hosted instance
A stack with explicit boundaries
The web app and API run in a container, structured data lives in PostgreSQL and uploads live on persistent storage. External identity, AI or storage providers are present only when configured.
Application
Web · API · jobs
Persistent data
PostgreSQL · uploads
Optional
Identity · AI · storage
Real SwiftUI app capture · demo data
Open-source iOS implementation
The iOS client connects to the operator's instance.
The native SwiftUI app is built from the same repository and uses a configured server origin. Reachability, TLS and certificate validity are therefore part of the deployment model.
Configure the server origin for the target instance
Inspect web, API and iOS code in one repository
Use HTTPS for connections outside a trusted local network
Open source enables review; it does not secure deployment by itself.
The MIT license permits inspection, modification, operation and redistribution. It does not replace upgrades, backups or secure network configuration. Those responsibilities remain with the operator.
MIT license and source for web, API and iOS
Docker Compose, migrations, health endpoint and persistent volumes
Public issues and pull requests with visible revision history
