v4.0.14: Your Employee Builds You a Real Database With Its Own Web App, Backs It Up Every Night, and Checks Its Own Access Rules
Ask your employee for a CRM and it now builds you one. Not a spreadsheet, not a summary of what a CRM should contain: a working database with its own web application, its own address, its own users, and a backup running every night.
That is the whole of v4.0.14, and it is Enterprise edition.
What your employee actually builds
There is a new skill, gat-databases, installed by default. Your employee creates a database from a template (empty, CRM, contacts, invoices, inventory, tasks, projects, recruiting, expenses) and then keeps it up to date as you work.
Each database is a real web page with real typed columns: text, long text, number, currency, percent, checkbox, date, date and time, single and multiple select, email, phone, URL, rating, attachment, person, and links to other tables. Types are checked on every write. Columns can be required or unique, carry a default, and take colours, as can tables and individual choices.
The grid behaves the way you expect a grid to behave. Edit a cell in place or open the whole row as a form. Search, filter, sort, hide and reorder columns. Change a column's type and see a preview of which values would not survive the change before you commit. Import and export CSV, where an import can create a new table and guess its types.
It also has the spreadsheet comforts people quietly refuse to work without: select a range with Shift, set or clear values in bulk, move between cells with the keyboard, Enter to edit, Delete to empty, resize columns, and paste a block straight from a spreadsheet with extra lines becoming new rows.
Four ways to look at the same table
Every table can be shown as a grid, a kanban (cards grouped by a single-select column, drag a card to change its value), a calendar (by a date column, drag to change the date) or a gallery (by an attachment column, with thumbnails).
On top of that there is a dashboard of key figures and charts, bars, line or pie, built from SQL queries and updating live with the data.
And tables can be related to each other properly. A link column picks rows from another table by name. Rollup columns count, sum, average, take a min or max, or list values across that link, so the total of a client's deals is a column rather than an export. Formula columns compute things like {Price} * {Quantity}, with IF, ROUND, DAYS and CONCAT available, through a safe expression language rather than anything that evaluates arbitrary code.
You can also run read-only SQL against the tables by their real names, and save the queries you use.
The parts that matter when other people get access
Anybody can be given access with a link, an email and a password, at read, add, edit or admin level. Your employee can share a table when you ask it to.
The protection here sits in the engine, not in good intentions. Every request is checked against that person's role on the server, so a read-only account cannot write whatever the page lets them click. Passwords given by someone else are temporary: creation, invitation or reset, valid seven days, and at first sign-in the person must choose their own, at least eight characters and different from the temporary one, before doing anything else. A forgotten password can be reset by the owner, a database admin or the employee, which also closes any open sessions. Server code is never served. Backups run nightly with one-click restore.
On top of that, everything is recorded and almost everything is reversible. Every change to structure, rows or sharing is logged with who did it, when, from where, and the before and after values. Any change can be undone. Deleted tables, columns and rows go to a trash rather than into the void.
The employee checks the access rules itself, every time it matters
The skill makes the employee run a real checklist immediately after creating a database and after every critical change. It calls the site from outside without signing in and confirms nothing answers. It checks that roles actually hold, so a read-only person cannot write. It reviews who has access, the API keys, the webhooks and the public forms. It re-reads any code it changed itself. And it confirms a recent backup exists.
That is a solid self-check, and it is worth having precisely because the thing building the application is an agent. It is not an audit, and it is not a guarantee that there is no flaw. The guarantees come from the engine described above; this is the employee verifying its own work against them, every time it matters.
Backups you do not have to think about
Each database backs itself up into its own folder, never served online, gzip compressed, and counted against the employee's disk space.
It runs every night and again right before the first change of any day, with no new copy when nothing has changed, keeping the last 15. On demand from the page or by the employee, keeping 15. And automatically before every restore, keeping 5. If a nightly backup fails, the employee is told immediately rather than discovering it during a restore.
Admins restore any backup from Settings > Backups. Tables, rows, people and history are replaced in a single transaction.
Being kept informed without being buried
The employee that creates a database is linked to it and told about every change other people make: through the page, by other employees, via forms, via webhooks. Its own changes are not echoed back to it.
That could easily become noise, so you choose the rhythm: every change, or at most every 5, 10, 15, 30 or 60 minutes, or once a day. The default is five minutes. The first change in a quiet period goes out immediately and opens a window, the rest are grouped and arrive as one message when it closes. Questions asked in the page always go straight through.
The same batching now exists for webhooks generally, through an X-Webhook-Batch-Minutes header, with the queue surviving a restart.
Ask, automate, collect
There is an Assistant tab where people using the page ask questions about the data. The employee receives them, looks up the answer and replies, and the answer appears live in the page.
Automations follow a simple shape: when a row is added, changed or deleted, optionally when a column becomes a particular value, then notify the employee, call a URL, or set a value.
Public forms give you a link anyone can use to add a row with the fields you choose, which covers contact forms and intake requests without building anything.
Other employees connect with an API key at a level you choose, and webhooks send every change, signed, to another service or to an employee. An inbound webhook adds rows from outside.
It is yours to change
The page is plain HTML, CSS and JavaScript sitting in the database's folder. Ask your employee to change the look, the wording or the views and it will, because there is no framework in the way. It follows Geta.Team's light and dark themes, and it adapts on a phone, with the rail becoming a drawer and secondary actions moving into a "⋯" menu.
It also has to be named like something real. "CRM Acme" or "Invoices 2026" will pass; a bare template name is refused. Each database gets its own address, and can be renamed or moved later. The logo and favicon default to your instance's, or your white label's, and can be replaced with any image.
Published sites got safer and faster
Server code is no longer downloadable. On full-stack sites, files in the functions folder, the code that runs on the server, could be fetched as static files. They now return 404.
Worth being precise about the scope, so you can judge it correctly: what could be read was the site's server code. The data, meaning the database and uploaded files, and the site's secrets were never served. It exposed the logic, not the data. It is still the line in this release to act on if you self-host and publish full-stack sites.
Scheduled functions let a full-stack site have one of its functions called daily, at a fixed minute inside a UTC window, with each site getting its own minute so runs spread out. Schedules survive restarts. The databases use this for their nightly backup.
Bursts no longer fail. Function calls now queue in order for up to 30 seconds rather than erroring, and a running function no longer holds a database connection for its whole run. Measured: 100 simultaneous reads or writes on one site all succeed, in about 2.5 seconds for the whole burst.
And a fix for anyone running an employee's published site: changes made by an employee's own command now broadcast live to open pages, which previously only happened for changes made from a browser.
New instances start in about 25 seconds
The memory engine's libraries, roughly 300 MB, were downloaded on every first container start, before Geta.Team itself came up. A new instance or a recreated container could sit down for 10 to 20 minutes when that download was slow, and some deployments failed outright. Those libraries now ship inside the image, so nothing is downloaded at start.
Want to test the most advanced AI employees? Try it here: https://Geta.Team
