Closing the Last Mile: AI Employees Now Ship Live Websites in One Command

You ask your marketing strategist to spin up a landing page for next week's product launch. She drafts the copy, generates the hero image, writes the HTML and CSS, and hands you a folder of files. Now what?

If you have ever lived this moment, you know the answer. You download the folder, fight with a hosting account, push the files to Netlify or Vercel, configure the domain, watch the SSL provisioning spinner, and finally get a live link, probably twenty minutes after you wanted to share it with the team.

That last mile is where most AI generated content goes to die. The agent did the creative work. You did the logistics. With v2.1.17 of Geta.Team, that gap is closed.

What's new: the web-publish skill

Every employee on Geta.Team now ships with a new skill called web-publish. It does exactly what it sounds like. Your AI employee points the skill at a folder inside its working directory, and the platform returns a public URL on your instance, served directly from your self hosted environment, no third party hosting account required.

A single command:

node ./.skills/web-publish/cli.js publish /data/my-report

Returns:

https://your-instance.geta.team/web/abc12345/

That URL is live the moment the command finishes. Share it with a client, send it to a colleague, drop it in Slack. The content lives on your infrastructure, under your domain, under your control.

What you can actually ship with it

The skill takes a folder of static files and serves it as a website. In practice, that means your employees can now ship:

• Landing pages for product launches, beta sign ups, events, or campaigns
• Reports and dashboards built as standalone HTML files (think quarterly review for a client, financial summary for the board, analytics snapshot)
• Client deliverables like mockups, prototypes, design reviews, or handover packets
• Internal documentation sites, runbooks, and team wikis
• Single page apps with client side routing, thanks to built in SPA mode
• Demo environments for product walkthroughs and pitch decks

Anything that can be expressed as a folder of HTML, CSS, JS, and assets is fair game.

A few details that matter

This is the first version, so we kept the surface small and the defaults sensible. A few things worth knowing.

Public by default, private when you need it. Sites are open to the world unless you flip them private, which adds HTTP Basic Auth with a username and password you set at publish time. Useful for sharing draft work with a client without indexing it on Google.

SPA mode for client side routing. If you are publishing a React, Vue, or Svelte build, add the --spa flag and every unmatched route falls back to your index.html. Refreshing /about no longer breaks.

Themed 404 page. When someone hits a wrong URL, they get a clean dark or light card that respects their Geta.Team theme preference, not a plain text "Not Found." Small touch, but it makes the published sites feel like part of your product, not a server default.

Custom slugs. Let the platform auto generate a short hex slug, or pick your own. The slug rules are lowercase, kebab case, up to 64 characters. So you can publish /web/q2-board-review/ instead of /web/a3f81b9c/.

Sidebar management. A new Websites entry in the dashboard sidebar lists every site your employees have published. Edit the slug, toggle privacy, rotate credentials, or delete the binding from one place. Admins see every site on the instance, non admins see only their own employees' sites.

The safety net you don't have to think about

Letting an AI agent publish to a public URL is exactly the kind of feature where the failure modes can be catastrophic. We thought hard about this before shipping.

Path scoping is strict. An employee can only publish from its own working directory or the shared team folder. There is no way to point the skill at an arbitrary system path, the platform's source code, or another employee's files. Every public request re verifies the resolved path against the allowed root, so a symlink created after publish time cannot escape the sandbox.

Secret files are blocked at publish time. If a folder contains a .env file at its root, the platform refuses to publish it and explains why. Your agent's own credentials never leak to the public web. Dotfiles are also ignored by the static server as a second layer of defense.

Passwords are bcrypt hashed. Basic Auth credentials are never stored or returned in plaintext. If a password is lost, the Edit panel resets it.

Hardened HTTP headers. Every published response carries X-Content-Type-Options: nosniff and Referrer-Policy: no-referrer, with a permissive but scoped Content Security Policy so your inline scripts and external assets work without weakening the rest of the app.

Why this changes the loop

Geta.Team has always been about employees that actually execute, not chatbots that suggest. Drafting content is execution that stops one inch short of the finish line. Adding the ability to ship means an entire category of work, building and delivering websites, reports, and microsites, now happens end to end without a human stepping into the logistics.

A few concrete loops this unlocks:

• A sales rep generates a personalized one pager for a prospect after a discovery call, publishes it as a gated URL, and emails the link in the follow up.
• A customer success manager builds a status report for a strategic account every Monday, publishes it under the same slug each week (the URL stays stable), and the account team checks the same page on demand.
• A marketing strategist runs a small campaign, ships the landing page and a thank you page on the same instance, and iterates on the copy without redeploying anything.
• A data analyst exports a dashboard as a static HTML snapshot at month close, publishes it privately, and shares the link with the executive team.

In each of these, the employee owned the work from intake to delivery. No human was conscripted to be the deployment bot.

Available now

The web-publish skill is included by default for every new employee, and existing employees pick it up automatically on the next skill sync. There are no quotas in v1. Sites per employee and folder size are both unlimited.

Try it on a Geta.Team Enterprise instance today. Ask your virtual employee to build something. Then ask her to publish it. You will get a link back before you finish the sentence.

Want to see what self hosted AI employees can ship for your team? Start at geta.team.