REI3: a self-hosted low code platform for internal business applications

The pitch is ownership of the data and of the applications

REI3 describes itself as free and open low code, with the subtitle build and host applications with full control and ownership, and the positioning line in the README is about escaping constraints rather than about convenience. Free yourself from walled gardens and cloud-only SaaS offerings, it says, and REI3 enables low code applications, selfhosted in the cloud or on-premise, which you can then create and use, share or even sell.

That last clause is the unusual one. This is not framed as an internal tool only. The feature list supports it, with an applications gallery at rei3.de, a live demo, and the topics covering application-builder, business-software, internal-tools, selfhosted, no-code and low-code.

The feature list is long and each item maps to a real internal-tool requirement. Fast results, replacing spreadsheet solutions with proper multi-user applications. It can count, summarizing records, doing date calculations and applying business rules. Make things visible, with Gantt charts, diagrams and information-dense lists. Workflows included, adjusting forms based on the current state of a record, exporting to PDF and sending notifications. Compliance tools, giving and restricting access globally or per record through roles and access policies. End-to-end encryption with integrated key management. Integration options, serving and calling REST endpoints, creating or importing CSV files and offering ICS for calendars. Ready for mobile, with specific mobile settings and PWA features. Fulltext search with language specific lookups. Many inputs available, from date ranges to drawing inputs for signatures to barcode and QR code inputs that can scan codes via camera. Security features, applying password policies, blocking brute-force attempts and enabling MFA. Fully transparent, reading and even changing data directly in the REI3 database because everything is human-readable. Selfhosted, with control over where the data is located. Enterprise-ready, adjusting to your corporate identity, managing users and access via LDAP and growing by extending applications and clustering.

That last group of features is what separates it from a generic form builder, and it is also the part that determines whether you can run it.

One Go binary on Postgres, with the database treated as the source of truth

The README is thin on internals, but the repository layout and the module file say a lot.

The top level has a `db/` directory, a `schema/` directory, `repo/`, `handler/`, `request/`, `login/`, `cluster/`, `ldap/`, `scheduler/`, `spooler/`, `transfer/`, `tools/`, `cache/`, `backup/`, `bruteforce/`, `log/` and `www/` for the frontend assets. The entry point is `r3.go`. That is a conventional Go web application layout, with the domain logic in `repo/` and the HTTP surface in `handler/`.

The module is `module r3` with a Go version of 1.27.1. The dependency list is where the platform's capabilities become concrete, because each library corresponds to a feature in the README.

For the database, `github.com/jackc/pgx/v5` is the PostgreSQL driver, and the go.mod also lists `go-sql-driver/mysql`, `microsoft/go-mssqldb` and `nakagami/firebirdsql`, so the persistence layer is not Postgres-only even though the quickstart configures Postgres. `codeberg.org/go-pdf/fpdf` is the PDF generation behind the export feature. `github.com/arran4/golang-ical` handles the ICS calendar output, and `github.com/emersion/go-imap` and `go-message` are there for mail. `github.com/gorilla/websocket` is the bidirectional data channel the README mentions. `github.com/boombuler/barcode` covers the barcode and QR inputs, `github.com/xlzd/gotp` is the one-time password support behind MFA, `github.com/coreos/go-oidc/v3` and `golang.org/x/oauth2` cover the OIDC and OAuth flows, `github.com/go-ldap/ldap/v3` covers LDAP, `github.com/wneessen/go-mail` is the outbound mail, and `github.com/kardianos/service` is what makes the binary installable as a system service on Windows.

The ClickHouse driver is also present, which the README does not mention, and it is a reasonable guess that it exists for analytics or export workloads rather than for the transactional path.

The transparent-database claim is the design commitment. The feature list says you can directly read and even change data in the REI3 database and that everything is human-readable. That is a deliberate architectural position, and it is the opposite of a platform where your data is only reachable through the vendor's API.

Four steps on Linux, and a default admin password you have to change

The Linux quickstart is four numbered steps, and the third one is the step that trips people up.

First, extract the package for your architecture, x64 or arm64, to any location such as `/opt/rei3`, and make the binary `r3` executable with `chmod u+x r3`.

Second, copy `config_template.json` to `config.json` and fill in the details of an empty, UTF-8 encoded Postgres database. The database user needs full permissions on that database.

Third, install the optional dependencies. ImageMagick and Ghostscript are needed for image and PDF thumbnails, and the PostgreSQL client utilities are needed for integrated backups, with the commands given as `sudo apt install imagemagick ghostscript` and `sudo apt install postgresql-client`.

Fourth, register with `sudo ./r3 -install` and start it with your service manager, `sudo systemctl start rei3`.

Once running, REI3 is available at https://localhost on the default port 443, and the README says both the username and the password are `admin`.

That default credential is the first thing to change on any installation that is reachable by anything other than you. The application is served over HTTPS on 443 by default, which is a sensible default for a system that will hold business records.

On Windows the path is the installer for a standalone version on any Windows Server, with Ghostscript optional for PDF thumbnails. There are also Docker Compose files for x64 and arm64, and a portable Windows version, both described as a quick way to set up a test or development system.

The proxy note about websockets is the operationally important line

One sentence in the quickstart deserves more attention than it gets. If you plan to run REI3 behind a proxy, the README says to make sure to disable client timeouts for websockets, with a link to the admin documentation.

The reason is in the feature list. REI3 communicates with clients over bi-directional data channels, and the `gorilla/websocket` dependency is the implementation. A proxy that applies a default read timeout will close an idle websocket connection, and the symptom on the client side is a dashboard that appears to work and then stops updating.

This is a small operational detail with a disproportionate effect, because the failure mode looks like a bug in the application rather than a misconfigured proxy. If you are putting REI3 behind nginx, a load balancer, or an ingress controller, that timeout is the first setting to check.

The clustering feature interacts with the same area. The feature list says you can grow with your organization by extending applications and clustering REI3, and the repository has a `cluster/` directory to match. Clustering implies several instances behind a proxy, which is exactly the configuration where the websocket timeout matters and where the Postgres instance becomes shared state you have to think about.

A licence file per component, and what that implies

The licence situation is unusual and worth reading carefully. The repository metadata reports the licence as Other, a custom licence that GitHub cannot classify, and points at the LICENSE file.

What is actually in the repository is a set of five licence files, `LICENSE.Apache-2.0`, `LICENSE.BSD-2`, `LICENSE.GPL-3.0`, `LICENSE.ISC` and `LICENSE.MIT`, plus a `LICENSE.md` that presumably explains how they combine. That pattern is what you see when a project ships third-party components under different terms and needs to keep them separate from its own.

The likely reason is visible in the dependency list. The Go dependencies carry their own licences, and a project that vendors or redistributes parts of them has an obligation to keep those notices with the code. It is a pattern that shows care rather than sloppiness.

For an adopter, the practical step is to read `LICENSE.md` and see which terms apply to the parts you are actually using. This is not legal advice, and the difference matters most if you intend to redistribute REI3 or to build a commercial application on top of it and sell it, which the README explicitly contemplates. The `LICENSE.md` file is the place that answer lives, and it is short enough to read before your first deployment rather than after.

One more point on the terms of use. The README frames the platform in terms of escaping cloud-only SaaS offerings, and the enterprise-ready feature list mentions adjusting REI3 to your corporate identity and managing users through LDAP. Those are the parts that make the self-hosting pitch credible for an organization with existing infrastructure.

Compared with a hosted low code platform and with a custom application

The two realistic alternatives differ in what you own afterwards.

A hosted low code platform gives you the application quickly and nothing else. The data lives on the vendor's infrastructure, the pricing model is per user or per app, and the applications you build are bound to that platform's model. The difference in approach is that REI3 makes the database the primary artifact, human-readable and directly editable, and the README is explicit that you can read and even change data in it. If the vendor raises prices or changes their terms, the data is still yours and the app is still yours.

The cost is that you run it. There is a Postgres database to provision, a binary to register as a service, a reverse proxy to configure, and upgrades to perform. The README does not describe an upgrade path, so that work is yours to plan, which is a real difference from a hosted product where the version is someone else's problem.

The second alternative is to build the application properly, with a framework, a database of your choosing and code you maintain. The difference in approach is that a custom application can do exactly what your process requires, including the awkward parts, whereas a low code platform constrains you to what its model supports. A custom build costs development time up front and maintenance forever, and it usually needs a developer for every change. REI3 moves that work to the person who configures the application, at the cost of living within the platform's data model.

There is also a third consideration, the one the README leads with. The people who build applications with a low code tool are often not developers, and if your internal tools are going to be maintained by the people who use them, that changes which option is realistic. REI3 also says you can share or even sell your applications, so a platform that supports that is a different proposition from a general-purpose business application framework.

Editorial conclusion

Adopt REI3 if you are replacing spreadsheet-based internal processes with a multi-user application, you want the data to stay on infrastructure you control, and you are prepared to run and upgrade the platform. Do not adopt it if you need a hosted product with a support contract, or if you expect to hand the finished application to non-technical staff without a browser, since it is still a web app you operate. Verify first that the Postgres instance you point it at is one you can back up and migrate, and that your reverse proxy does not time out websockets, which the README calls out explicitly.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. r3-team/r3 on GitHub
4. README
5. Releases