v2.8.0: Your Employees Now Ship Real Apps With a Database, Put Them on Your Own Domain, and Join Your WhatsApp Groups

The version number went from 2.7 to 2.8 for one reason. Until this release, when your employee published a website, it published a website: files, a URL, done. Now it can publish an application. A real one, with a database, server-side functions, webhooks, live realtime channels and your own domain on top.

The rest of the release is good too, and WhatsApp groups will make more people happy day to day. But the interesting part is what an employee can now build for you between one conversation and the next.

Your employee can ship a real app now, not just a page

Functions in a published project now run on a trusted Node.js runtime. That means the normal things: require, fetch, timers, installed modules, WebSocket clients, the project filesystem and direct database access. No miniature sandbox with a curated list of what you're allowed to call.

Each project gets its own SQLite database. You get parameterized queries for everyday work and raw SQL when you need it, including transactions, PRAGMA, triggers, temporary tables and full-text search. The CLI can export a consistent snapshot, run an integrity check on import and swap the live database atomically.

All of it lives inside the project folder. The database, uploaded files, every deployed version of every function and its backups sit together under .gat/. Copying that folder is a complete backup. Republishing it restores your data and your working functions. Unpublishing only removes the public address, so nothing is lost when you take a site offline.

On top of that:

• Webhooks accept raw bodies, so signed payloads survive byte for byte, and functions can return binary responses.
• WebSockets are native, with ordered connect, message and close events, and a broadcast that works across backend workers. No polling anywhere.
• Realtime channels let a browser subscribe to a channel directly. Functions mint short-lived tokens scoped to specific channels and permissions, so your credentials never appear in frontend code. Messages are stored encrypted at rest with a per-project key, and clients replay what they missed after a reconnect.

To stop ourselves from grading this on a generous curve, the yardstick we wrote for it isn't a demo endpoint. It's a server-authoritative 1v1 reaction game with best-of-seven matches, false starts, decoys, sudden death, spectators, leaderboards and explicit rules for two people clicking at the same millisecond, plus anti-cheat and encrypted-at-rest checks. That full run is still ahead of us, and we'd rather say so than imply the box is ticked.

Your own domain, in three steps

A published site can now live on a domain you own. In the Dashboard's Websites panel there's a three-step assistant: type your domain, add two DNS records, press verify. It tells you where DNS settings usually hide, shows the exact Type, Name and Value with copy buttons, offers an A record when your provider refuses a CNAME on the root, and gives you a useful message instead of a shrug when the TXT record isn't visible yet. Verification runs when you ask it to, never on a polling loop, and a pending challenge expires after 24 hours.

Employees can do the same from the command line with domain add, domain list, domain verify and domain remove. Certificates are issued and renewed automatically. The original /web/ address keeps working. Administrators can manage every site, and everyone else manages the sites their own employees own.

Behind the scenes, every web server change is backed up, tested and only then applied, and anything that fails rolls back to the previous working configuration. This is the part of the system where a typo takes a site off the internet, so it's built to refuse rather than to improvise.

WhatsApp groups

Employees can now work in WhatsApp groups. They can list the groups their account belongs to, read a conversation with both the group and the actual sender clearly identified, and send text or media to a specific group. The inbox filters by direct or group, or by one particular group.

Group access is off by default and stays behind its own permission, with a deliberate split: Allow group messages gives read-only access, and Allow employee replies in groups must be switched on separately before your employee can post anything. With replies off, the employee isn't even told how to send, and the backend refuses the attempt anyway. Direct messages keep their own separate rules.

Messages you post yourself from the connected account now reach the employee too, so it follows the conversation properly, while its own messages stay filtered out to avoid it replying to itself.

Pairing that stays paired

Two connection types that used to drift quietly are now solid.

Desktop. Connections no longer stop working when their pairing token expires. Access renews before expiry, retries once after an authentication failure, and refresh tokens rotate on every renewal, with replaced credentials revoked. Pairing also refreshes the employee's desktop-control skill, including for employees hired before this release. One thing to do after upgrading: pair the Desktop App once, so it picks up a refresh token.

Browser. Assigning browser access used to send credentials through a hidden chat prompt and rely on the employee to edit its own configuration file. Extension version 1.2.11 replaces that with a proper pairing route. The backend issues the tokens, refreshes the skill and writes the whole credential set in one go before it reports success. An assignment can't quietly half-succeed any more, the status only says assigned when everything is genuinely in place, and the button is now a real toggle: press it again to unassign, which revokes the token and tells the employee it no longer has access. The prompt the employee receives contains no credentials at all.

Conversations that know where they came from

Conversation History now knows which engine each session belongs to. If a session was run by a different engine than the one your employee currently uses, Continue is disabled and says why, rather than failing in a confusing way later. Unknown metadata fails closed.

Resuming a native Codex conversation works properly now, and the interface switches to the conversation you picked immediately instead of showing you the previous one for a moment. History stays responsive after a reconnect, sessions open with proper loading and error states, and a polling loop that checked for updates every half second is gone.

Changing an employee's intelligence is safer too. Switching from Codex to Claude, or between any other providers, can no longer be quietly reversed by a reconnect arriving at the wrong moment, and the provider saved on the employee is now the authority. Resetting a conversation or changing intelligence also keeps you on the chat screen instead of dropping you back at the Dashboard.

Smaller things you'll notice

Tool rows keep their summary short, with the full command available on hover, so an expanded tool list doesn't shove the file panel sideways. Markdown previews stay inside their panel, with only code blocks and tables scrolling on their own. And a Markdown link pointing at one of your employee's files now opens that file in the File Explorer instead of trying to load it as a web page.

One thing we are not hiding

This release included a security pass on Web Publish that closed three ways a function could have reached outside its project: connections to internal, private and cloud metadata addresses are refused, symbolic links pointing out of a published folder return 404, and a folder swapped after publication fails rather than writing anywhere unexpected. Functions also no longer see the raw cookie header, only their own project's cookies.

One known limitation is worth stating plainly. Sites served under /web/<slug> share an address with the application itself, which means scripts on those pages can read the platform token from browser storage. The fixes available today would break existing sites, so we've left the behaviour as it is for now. Sites on a verified custom domain have their own origin and aren't affected, so if you're publishing something with real data in it, put it on your own domain. That's a better home for it anyway.

Want to test the most advanced AI employees? Try it here: https://Geta.Team