v4.0.20: Studio Opens Your Existing Repo and Your WordPress Site, and Your Server Warns You Before the Disk Fills
Studio shipped yesterday for projects that start empty. The obvious question came back immediately: what about the app I already have? v4.0.20 answers it twice. The new project screen now has three tabs instead of one. Create something new, open an existing app from git, or connect a WordPress site you host yourself.
Your repository, in the Studio
Point it at a repository on GitHub, GitLab, Bitbucket or any git server, private ones included. The Studio shows your employee's own SSH key and exactly where to put it: a deploy key with write access, scoped to that one project. Nothing else is stored, and you can remove the key whenever you like.
Before any of that code runs, it gets read. The scan looks for what is known to hide malicious code: backdoors, web shells, crypto miners, install scripts that download and execute things, PHP sitting in an uploads folder. It also looks for secrets left in the repository and dependencies with known flaws. Anything serious blocks the preview until you have looked at it and decided. The findings are written in plain words, in your language, with a button that asks your employee to fix them, and the check runs itself again whenever the dependencies change.
This matters more than it sounds. You are pointing an AI employee at a codebase that may not be yours, may be years old, and may contain something nobody remembers putting there.
Previewed in a box
How your project runs depends on what it is. Static sites are served as they are. React and Astro apps get built. Next.js and Vite apps run as development servers, so a change appears on the next load without waiting for a build, while the quality check still scores the production build your visitors would actually receive. Node servers and PHP run as they are.
All of it runs inside a container with no internet access, capped resources and no privileges, and only while the Studio is open. The preview is also served from an address separate from Geta.Team itself, so your browser holds the repository's code apart from your Geta.Team session: it cannot reach it.
While a server preview starts, you watch it start: the output appears line by line and turns into your app the moment it answers. If it dies on the way up, you get the end of the log, a Try again button, and a button that asks your employee to find the cause and fix the code. It does not sit there restarting in a loop while you read.
Publishing is a push, not a deploy
When you publish a git project, the change is pushed to the branch. Never forced. Your own hosting deploys it the way it always has.
Before each publication a tag records what the branch was, plus a backup tag the first time, so any previous version comes back in one click as a new commit rather than a rewrite of history. If somebody pushed while you were working, their work is brought in first. A database migration stops and waits for you to confirm your database is backed up. Dependencies, build output and preview caches are never pushed. The commit message is drafted from what your employee noted while working, and redrafted after any fixes the quality check asked for.
Everything else from the Studio works here too: hand edits written into the source rather than a build folder, PHP files included, three versions side by side, the quality check before each publication, before and after against the last published version, the draft on your phone by QR code. Keyboard shortcuts work with focus inside the preview, and several people on one project see each change as it lands.
WordPress, without installing anything
The third tab connects a WordPress site you host yourself, using an application password. Nothing gets installed on the site, and the password can be revoked from WordPress at any moment. The screen walks you through it: the site address, how to create the password with links straight to the right WordPress page, then the user name and the password. The connection is tested before anything is saved, with a clear message when something blocks it: wrong password, REST API switched off by a security plugin, an account without editing rights.
The preview is the live site, with its links staying inside the Studio. Comments pin onto it like any other project, and it reloads after each change.
Your employee edits pages through WordPress itself, as Gutenberg blocks. Before it writes a page it checks the page has not changed in WordPress since it last read it, and if it has, it stops and reads it again rather than writing over somebody's work in the admin. Undo follows the same rule.
Pages built with Elementor are recognised and left alone. Not left alone unless you ask: left alone full stop. Ask your employee to change one from the Studio and it will tell you it cannot do that from there yet, which is the right answer and better than a mangled layout.
Every change made from the Studio is listed with which page, what changed, who did it and when, and any of them can be undone in one click. The Studio keeps its own copy of the page as it was, so undo works even on hosts where WordPress revisions are turned off.
For admins: Studio limits and a disk that warns you
A Studio card in the admin settings caps how many Studios can be open at once on the instance, four by default, with a project open by several people counting once, and sets the CPU and memory each one gets, 1 vCPU and 2 GB by default for its preview, builds and quality checks. Past the limit the next Studio says so, shows its place in the queue, and opens by itself when a place frees up.
There is also a bin on every project now. Deleting says exactly what goes: for a git project, only the Studio's copy, since the repository is never touched; for a published site, the live site too. Your employee is told. Only the employee's owner or an admin can delete.
The one admins have been asking for: a Disk sheet showing the instance's disk, what each employee takes, its folder and its container, and Docker's own space. Two thresholds in the settings, a warning at 75% used and critical at 90% or under 10 GB free, each raising a banner on every page for every admin. The banner clears once you drop back under. It rides along with the server's existing health check every 30 seconds, which is the difference between knowing a week early and finding out when the instance stops.
More than one mailbox per employee
An employee can now hold several custom mailboxes, sales@ and support@ for instance. One is the default, starred in the connector, changed in a click. It sends from the default, or from another when it picks one, and a reply to a message that arrived in a given mailbox goes back out from that mailbox automatically. An address that is not one of its own is refused, so nothing ever leaves from an address it was not meant to use.
Also: a multilingual Studio site now opens in the visitor's browser language when it has that language, falling back to its default. The site's own switcher still works, and nothing is stored on the visitor's side. No cookie.
Long conversations now restart themselves
A conversation that keeps growing is resent in full on every turn. It costs more, it slows the replies down, and it makes them less accurate. The chat now counts the session's messages at the end of each turn, so a task is never cut in half. From 2,500 messages a banner suggests a new session with a button to start one. From 5,000 it insists. At 8,000 your employee is first asked to save what matters to its memory, the context, the decisions, the work in progress, and then the session resets and a new one opens by itself. It says so in a short message and carries on. Same behaviour whether the messages come from the chat, WhatsApp, Telegram or email, on Claude and custom LLM employees.
Two smaller Studio changes: a hand edit on a text that also appears in the page title or a meta tag now lands where you are looking at it, and the history says who did what, a person editing by hand or picking a version, or the employee with the name of whoever asked and their actual words. Useful now that several people share a project. The languages window also starts from the languages the site already speaks rather than from nothing.
Fixed
When the instance's Claude account loses its session, the chat used to repeat Claude's raw "OAuth session expired" response. Admins now get a clear notice with a Reconnect Claude button that opens the same reconnection flow as Settings, and everyone else is told to ask an admin.
The quality check's button to fix the remaining items stayed stuck on "Sent" after a round of fixes. It comes back now when something is left.
Robots knocking on the public SIP port had the telephony server logging one line per rejected attempt, thousands an hour, which could fill a server's logs and, left unchecked, take an instance down. Only warnings and errors are written now. Calls are unaffected.
And in Chrome extension 1.4.5, the Stop button no longer switches off browser automation entirely. It used to flip the setting, after which the browser refused every employee until somebody found the switch again. Stop now ends only the task running at that moment. Browsers left switched off by the old behaviour are turned back on by the update.
