# Structr: a low-code platform where the application definition is a graph in Neo4j

> Structr is an open source low-code development and runtime platform that stores schemas, UI definitions, templates, scripts, workflows and the application data itself in a Neo4j graph. The GitHub repository is a clone, and all development has moved to GitLab.

**structr/structr** — ATTENTION: This repository is a clone of https://gitlab.structr.com/structr/structr. All development/issue tracking has moved there. | Structr is an integrated open-source low-code development and runtime environment that uses a graph database (Neo4j).

- Repository: https://github.com/structr/structr
- Website: https://structr.org
- Stars: 828 · Forks: 161
- Language: Java
- License: NOASSERTION
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/structr-structr

## The application and its data live in the same graph

Structr is described as an open source generic low-code development and runtime platform built on graph technology, and it is not limited to any predefined use case. It supports fully custom applications, including web applications, graph-database-backed backends, data-centric systems, middleware and integration components.

The core decision is that Structr uses a graph database to store both application components and application data. The application components are the schema, UI definitions, templates, scripts and workflows. The application data is what the running application produces. Both live in the same graph, and the README names the payoff as schema flexibility, fast graph traversals and expressive data modeling without join-heavy queries.

That single decision explains most of the rest of the platform. If the schema is a graph object, then changing it at runtime is a graph operation, which is why the schema editor supports runtime schema evolution. If UI definitions are graph objects, then a page is a node you can traverse, which is why dynamic repeaters can be bound to graph queries. If the schema can be represented as JSON Schema, then import and export work, and the REST surface can be generated from the same definitions rather than maintained by hand.

The file layout backs this up. There are separate modules for the embedded Neo4j driver and the Bolt driver, a db-driver-api module, a memory driver, and a modules directory, so the storage backend is behind an interface rather than hard-wired.

## A list of what Structr is not, which is the most useful paragraph

The README has a section titled What Structr is not, and it is the most informative part of the document for anyone evaluating the platform.

Structr is not a prebuilt business application, with a CMS, CRM and ERP named as examples. It is not a fixed-purpose framework with predefined domain logic. It is not a website builder with limited customization options. It is not a collection of templates tied to a specific industry. And it is not a replacement for general-purpose programming languages.

What it is instead is a generic application platform providing the building blocks, abstractions and runtime needed to design, build and operate your own applications within a controlled and extensible environment.

The point of stating the negatives is that low-code platforms are usually sold as a way to avoid choosing. This one is the opposite: it sells the runtime and the modelling environment, and leaves the domain logic to you. A team looking for a ready-made CRM will find nothing here, and a team with an unusual domain model and a willingness to write the logic will find a platform where the logic runs in scripts rather than in a source tree.

It also explains the AI angle in the README. Instead of letting an AI system generate unconstrained source code, Structr limits the interaction to explicit schemas, structured tools, isolated scripts and well-defined APIs, so the AI operates within well-defined boundaries.

## Two interfaces: the IDE that edits the graph, and the app it serves

Structr separates application development from application usage through two different web based user interfaces, and keeping them apart is the design.

The first is the Structr Developer and Admin UI, an integrated development environment exposed through the browser. It is used to modify the application graph, the part of the database that defines the application. The README is explicit that a Structr developer typically does not create or edit a raw source code tree. Development happens by editing high-level artifacts stored in the graph: schemas, types, properties and relationships, isolated script expressions and methods, HTML templates and UI definitions, virtual files with custom metadata, and configuration and operational settings.

The second is the end-user application UI, which the developer builds with the IDE tools and Structr serves directly. Pages, templates, bindings and workflows are defined in the graph and can be evolved at runtime.

The tool inventory under the Admin UI shows how wide that surface is. Platform and operations gives a dashboard with system information and runtime status, a server log and event log viewer, thread and job queue inspection, and deployment and environment information. Schema and data modelling gives a graph-based schema editor, type, property and relationship management, function properties with read and write scripting, and runtime schema evolution. Data management gives a graph-aware browser, spreadsheet-style CRUD editing, relationship linking, and bulk import from CSV.

Page and UI development gives a page and template editor, drag-and-drop components, dynamic repeaters bound to graph queries, templating expressions and localization, and a live preview of end-user pages. Application logic gives a script editor, polyglot scripting, runtime execution with result inspection, and OpenAPI exposure configuration for types and methods.

Files, graph exploration, workflows, security and localization round it out: a virtual filesystem browser with optional external binary storage such as S3, file access over HTTP, FTP and SSH/SCP, a visual graph browser with Cypher query execution, a node-based flow editor, user and group management with role-based and resource-based permissions, REST API access control and CORS configuration, and translation key and mail template management.

## GraalVM is the scripting layer and the JDK requirement

Structr supports polyglot scripting via GraalVM, which means you can use any language supported by GraalVM for scripts and methods. The Java badge in the README names GraalVM JDK 25 as the runtime.

This is a meaningful architectural choice rather than a detail. A platform that stores scripts as first class graph objects needs a scripting engine that can host many languages, and it needs one that runs the same way on the server and in the IDE, since the IDE has to execute and inspect the same expressions the runtime will. GraalVM gives both.

The cost is a specific toolchain requirement. This is not a container you can drop into an existing Java service; it wants a particular JDK, a particular scripting runtime, and a graph database next to it. The badges make the surrounding stack visible too: Neo4j as the database, a REST API with JSON, JSON Schema for the schema representation, event driven integration, FTP and SSH/SCP for file access, and Docker images published under structr/structr.

The Maven module layout in the repository reflects the same design. There is a structr-app module, a structr-base module, an annotation processor, a build extension, the db driver API, the memory driver, the two Neo4j driver modules, a modules directory and a test configuration module, all driven from a root pom.xml with a .mvn/ directory. The code style is documented in CODE_STYLE.md and dependency handling in DEPENDENCY_MANAGEMENT.md.

## The GitHub repository is a clone, and the GitLab one is the project

The repository description opens with a warning that should be the first thing a visitor reads. This repository is a clone of https://gitlab.structr.com/structr/structr, and all development and issue tracking has moved there.

That changes how you should treat the project. The GitHub tree is a mirror, so an issue opened here goes nowhere, a pull request opened here is not the review path, and the pipeline badge at the top of the README points at the GitLab pipeline for the main branch. The README links a publiccode.yml entry, which is the standard metadata file for European public sector software, and the repository is not archived, so the mirror is being kept in step rather than left to rot.

The licence arrangement is unusually explicit for a platform of this kind. The README badge reads AGPL v3 / GPL v3, and the repository root carries LICENSE-AGPL-3.0, LICENSE-GPL-3.0, LICENSE.md, NOTICE.md and COPYRIGHT.md, so there are two licences covering different parts, which is what you would expect from a product that ships as a hosted service and also as embeddable components. Read those files for the terms that apply to the part you intend to use, and this is not legal advice.

The last push to the mirror was on 2026-10-12 and the repository is not archived. There are no GitHub releases, because the release artefacts live in the GitLab project.

## Where Structr is the wrong tool

The first wrong fit is a team that wants the application definition in source control. The README says plainly that a Structr developer typically does not create or edit a raw source code tree, and that development happens by editing high-level artifacts stored in the graph. If your process is that the application definition is a set of files you review, diff and merge, then the primary deliverable of this platform is the thing you have decided not to have. The scripts are inside the graph, and the workflows and page definitions are inside the graph.

The second is a data model that is already settled. Structr's value is schema flexibility and fast graph traversals, which is exactly what you do not need when the tables are known, fixed and unlikely to change. A relational schema with a stable shape is cheaper to model than to graph.

The third is operational weight. Neo4j, GraalVM on JDK 25, a Java service and a browser IDE is a four part system to run and to keep running. The dashboards, the thread and job queue inspection and the deployment and environment information in the Admin UI exist because this is a server you operate, not a library you import.

The fourth is a hard requirement on a vendor's direction. The project is a commercial product with an open source core, developed by a small team on GitLab, and the feature set is shaped by what that team is building. The README even lists MCP enabling and GDPR compliance among its badges, which tells you where the roadmap is pointing, and a platform bet is a bet on that roadmap.

The fifth is a team that wants a framework rather than a platform. The README's own list of negations says Structr is not a fixed-purpose framework with predefined domain logic and not a replacement for general-purpose programming languages. If you want a conventional framework where you write Java or JavaScript files and call a router, this is the wrong shape, and the honest alternative is that approach: keep the code in a repository, and use a low-code platform only for the parts where modelling genuinely helps.

## Conclusion

Structr fits a team that wants to ship an application by modelling it in a graph and a browser based IDE, with polyglot scripting and an OpenAPI surface generated from the same definitions, and that is comfortable operating Neo4j and a Java service. It does not fit a team that wants its application definition in version controlled source code, or a project whose data model is fixed and known. Before adopting it, read the section of the README on what Structr is not, then evaluate the platform at gitlab.structr.com rather than the GitHub mirror.

## FAQ

### What is Structr?

It is an open source generic low-code development and runtime platform built on graph technology, written in Java on GraalVM. It uses a Neo4j graph database to store both the application components, meaning schema, UI definitions, templates, scripts and workflows, and the application data itself.

### Where does Structr development actually happen?

The GitHub repository is a clone. All development and issue tracking has moved to https://gitlab.structr.com/structr/structr, and the pipeline badge in the README points at the GitLab pipeline for the main branch.

### Can Structr be used for any kind of application?

It is not limited to a predefined use case and supports fully custom applications, including web applications, graph-database-backed backends, data-centric systems, middleware and integration components. The README explicitly says it is not a prebuilt business application and not a fixed-purpose framework.

### Which languages can Structr scripts be written in?

Structr supports polyglot scripting via GraalVM, so you can use any language supported by GraalVM for scripts and methods. The project targets GraalVM JDK 25.

### What licence does Structr use?

The repository carries LICENSE-AGPL-3.0, LICENSE-GPL-3.0, LICENSE.md, NOTICE.md and COPYRIGHT.md, and the README badge reads AGPL v3 / GPL v3. Read those files for the terms that apply to the part you use.

## Sources

- [Issues](https://github.com/structr/structr/issues)
- [Project website](https://structr.org)
- [README](https://github.com/structr/structr/blob/main/README.md)
- [structr/structr on GitHub](https://github.com/structr/structr)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/structr-structr