SELF-HOSTED

Running UR Maintain inside your own network.

One application, one data model — deployed on infrastructure your organisation controls. This page is what your IT team will need to plan for: what the installer does, what it deliberately does not do yet, and where the responsibility sits.

WHAT IT MEANS

Same product, your infrastructure.

Not a cut-down edition and not a fork. The same application code and the same data model, pointed at your environment.

Same codebase

One product, two editions

Managed cloud and self-hosted run the same application and the same data model. There is no “enterprise-only” feature set waiting behind a licence tier, and no re-implementation that drifts from the hosted version.

Your network

Nothing has to reach the internet

The application talks to your PostgreSQL, your object storage and your identity provider. Licence activation is specified to tolerate a dropped connection rather than to stop a plant maintaining its equipment because a check-in failed.

Data portability

A design requirement, not a favour

Portability is a stated requirement of the product, not something granted on request. Import works today; an export route and deletion workflow are open items and are listed as such on the product status page.

REQUIREMENTS

What your environment has to provide.

The specified baseline. Sizing is a starting point to be confirmed against your own load, not a guarantee.

Host

Linux and Docker

A modern x86_64 Linux host — Debian or Ubuntu class — with the Docker Engine and Compose plugin. Persistent NVMe or SSD storage. DNS and TLS for the address your team will use, and SMTP if you want mail.

Starting size

About 8 vCPU, 16 GB RAM and NVMe

The recommended starting size for a small production host, subject to measured workload. Because the architecture is a modular monolith rather than a microservice mesh, this is a real number rather than a floor for a dozen containers.

Dependencies

PostgreSQL, object storage, Keycloak

The reference topology runs the application, a background worker, PostgreSQL 16, Keycloak for identity, an S3-compatible object store and a reverse proxy. Dependencies are pinned to explicit versions — latest is not a deployment strategy.

No Kubernetes required

Docker Compose, deliberately

The deployment target is Docker Compose. The architecture explicitly rejects starting with Kubernetes, Kafka, Elasticsearch or a mandatory Redis layer. Horizontal replicas can be added later behind a load balancer when measured load justifies the complexity.

THE INSTALLATION BUNDLE

What the official package contains.

The bundle is built and documented, and its install, upgrade, rollback and destroy-and-restore paths have been rehearsed on a clean host with the transcript committed. Each technical item below exists as a file or a command your IT team can read; the responsibility split is the commercial half and stays as specified.

Built

Compose file, environment template, migrations

A versioned Compose file, a documented .env.example with configuration validation, the migrations, a reverse-proxy configuration for TLS, and a version report. Credentials are generated during installation — there are no default production passwords to forget to change.

Built

Health checks, upgrades, support bundles

A health-check command, an upgrade command, documented rollback notes, and a support-bundle generator that excludes secrets and your document and work-order contents by default.

Built

Preflight checks before anything starts

Installation checks CPU, RAM and disk, that the required ports are free, DNS and TLS, the Docker version, that volumes are writable, that the clock is synchronised, and that a backup destination is reachable — before it changes anything.

Specified

A responsibility matrix, agreed in writing

Who patches the operating system, who maintains the container runtime, who owns TLS and the domain, who runs backups and takes an off-site copy, who monitors, who supplies SMTP, who applies upgrades, who remediates vulnerabilities, who holds support access, and who responds to hardware failure and disaster recovery.

WHO DOES WHAT

The split, in one table.

Self-hosting moves responsibility, not effort. This is the division as specified.

Your organisation

Operating system patching, the Docker runtime, the host itself, network and firewall, TLS certificates and the domain, the backup destination and its off-site copy, monitoring the host, and the decision to apply an upgrade.

UR Maintain

The application, its migrations and its upgrade path, the security fixes for what we wrote, the supported version policy, the hardening guidance, and support access that is authorised, time-bounded and audited rather than standing.

What is still missing for either side

The reverse proxy, pgBackRest for PostgreSQL and restic for the object store all exist now, and the full rehearsal — install, upgrade, rollback, destroy the volumes and restore — has been run with its transcript committed. What is not there: no metrics or alerting backend, so watching the host is yours; nothing in the product reads SMTP yet; no licence is activated or verified by the software; and the keys that decrypt a backup are not escrowed or rotated by anything we ship, which is operational work no script does for you. The security page states this in full, and the status page tracks it.

IT EVALUATION

Send this page to the people who run your servers.

If their review raises a question it does not answer, ask us — we will tell you whether it is built, planned or missing.

Talk to us →