Define entities, fields, relationships and access in Generator UI. Admingen saves these settings to .admingen/project.yaml. This file, the manifest, describes the application to generate.
Develop the model and custom code alongside each other. Configure standard capabilities through the UI and write your logic in custom zones. Editing generated Go or React does not change the model and cannot replace manifest configuration.
Where to change settings
Project settings contains the project title and image storage. Startup layouts, CI and environment profiles are in Deployment. Content contains modules, entities, fields and relationships. Operation access and record visibility conditions are configured in Entity settings → Access.
Finish saves the model. To update application files, open Generate → Preview changes → Generate. This is a separate action: saving a form neither releases code nor changes the database.
Manifest sections
| Key | What it describes |
|---|---|
version |
Project contract. Currently 0.8.1. |
generatorVersion |
Generator version recorded in the project. Replacing the number does not upgrade the contract. |
project |
Technical name, interface title and Go module path. |
database |
PostgreSQL and database schema. |
auth |
Authentication, required for supported applications. |
modules |
Named entity groups and their order. |
entities |
Fields, relationships, CRUD operations, UI, access and projections. |
generation |
Backend, UI, API and migration technologies. |
deployment, media |
Deployment-file generation and image storage. |
features, ui |
Additional supported parameters and UI mode. |
fieldRenames |
Explicit field renames. This section does not indicate applied SQL migrations. |
After creating a project, regular configuration does not require manual YAML editing. For example, Article in Content is stored like this. This is a fragment, not a complete manifest:
name: Article
kind: persistent
module: content
table: articles
fields:
- name: id
type: int
primaryKey: true
autoGenerate: identity
- name: title
type: string
required: true
An entity has name, kind, module, table, fields, relations, crud, access and ui. Instead of its own table, a virtual entity uses virtual: source, select and operations. API and UI settings cannot enable an operation unsupported by the entity itself.
Checks before generation
The generator fills permitted defaults and checks types, names and references. This stage is normalization. For example, two primary keys, an incompatible foreign key or duplicate field alias stops processing. The diagnostic identifies what must be fixed in the model.
Entity names must be unique ignoring case, and relationships must reference existing entities. Table, route and file names derive from technical names under generator rules. Check the current plan and generated files: old examples may not reflect current naming.
Lock and baseline
The manifest stores current settings. lock stores the contract and generated-file hashes for change and ownership checks. baseline contains the exact model bytes from the last successful generation.
These files serve different purposes. Manually changing version in lock neither upgrades an old project's contract nor updates its data. Automatic compatibility with old contracts is not implied.
Continue
Use Generator UI for everyday work. Form details are in Project settings and Content.
CLI automates the same operations. If you edit the manifest manually, still check the model, plan and diff: manual editing does not bypass generator constraints.