The platform, improving.

Settings you change later now reach your app

Until now, a plain setting you added to your app's configuration after creating it never reached the running app: neither a new ghosty provision nor a new publish applied it, even though the instructions said they would. ghosty provision now applies your settings to the running app every time you run it, adding new ones and updating changed ones, and the Environment card shows them as "App config". To switch a setting off, give it an empty value and provision again; the platform never removes a setting on its own. Update to the latest CLI to get the corrected in-app guidance. docs →

Clearer diagnoses when a build fails or an app won't start

Two common situations used to come back from the diagnosis tool as "Ghosty couldn't pin down the cause": a build that failed on your own code, and an app that never started listening after a publish. Both now get a specific diagnosis pointing you to the build log or the runtime log, with the failing step named when it is known. Behind the scenes these outcomes are also no longer counted as platform errors, so the Ghosty team's alerts stay focused on problems only we can fix. docs →

See every setting your app runs with

Until now the console only listed the secrets you had created yourself. Your app also runs with settings the Ghosty platform provides — the database connection, file storage, the integrations gateway, your access-mode keys — and there was no single place to see them. The Secrets tab now has an Environment card listing every variable your app runs with, by name and by who sets it (the platform, one of your secrets, or your own app config). Secret values stay hidden, as always. The same list is available from the CLI with ghosty env and to your coding assistant through the list_environment tool. docs →

Secrets and local testing, explained

A secret you save on the platform reaches your published app right away, but it cannot reach your laptop: your local run only reads backend/.env.local. Three changes make that obvious instead of confusing. ghosty secret now asks for an optional local value and writes it to backend/.env.local for you. ghosty dev prints a heads-up for every secret that has no local value yet. And after you save a secret in the console, it shows you the exact line to paste. Secrets remain one value per app, shared by your published app and its previews. docs →

Fix: your first publish from the CLI no longer fails

Apps created with ghosty init and published with ghosty deploy could hit a "non-fast-forward" rejection on their very first publish, because the platform's setup commits and your local commits started from different roots. ghosty provision now reconciles the two automatically, ghosty deploy sets up tracking so git pull works afterwards, and if a push is ever rejected for this reason the error now explains it and gives the exact commands to run. Update to the latest CLI to get this. docs →

Every app on White Ghost now sits behind the Ghosty platform's protective edge — on by default for every workspace, no setup needed.

The edge screens every request before it reaches your app: injection attempts, automated vulnerability scanners, and request floods are blocked upstream, so they never consume your app's resources or clutter its logs.

This handles the internet's background noise — it doesn't replace your app's own sign-in, permissions, or input checks. Details, limits, and what to do if a legitimate request is ever blocked: docs →

Work on an app together

Every app has an owner, and now that owner can add any workspace member as a collaborator on one specific app. A collaborator can deploy it, roll it back, open previews, read its logs, manage its secrets, work against its database with their own development schema, and map a domain onto it — while your other apps stay entirely untouched. Deleting an app, transferring it, and managing the collaborator list stay with the owner.

Add someone from the app's Settings → Collaborators, from the terminal with ghosty collaborators add, or just by asking your coding assistant. Access to the app's code repository is granted automatically from the GitHub username on their profile. docs →

Removing someone now removes everything

When you remove a person from your workspace, their access ends everywhere at once: the apps they collaborated on, push access to those code repositories, and their personal access to the Ghosty database. Some of that could previously outlive the removal.

Also in this release

The ghosty CLI (0.28.0) adds the ghosty collaborators commands, and ghosty apps now marks which apps you own and which you collaborate on. Guidance when a deploy can't reach your code repository is clearer, pointing at the exact command that fixes it.

Your apps can now diagnose themselves

Deploys fail, apps crash, secrets go stale — and figuring out why used to mean digging through logs. Not anymore.

When something goes wrong, run ghosty report (or ask your coding agent to). The Ghosty platform gathers the evidence around your app — recent deploys, build output, runtime signals — and comes back with a verdict in plain language: what broke, whose side it's on, and what to do next. Most issues are recognized instantly; the trickier ones get a closer look from Ghosty's diagnostic engine. Either way, you get an answer instead of a log file.

If Ghosty can't figure it out, the report reaches our team automatically — you never have to file it twice. docs →

Your coding assistant can now drive Ghosty

The Ghosty CLI now includes a built-in tool server for coding assistants (Claude Code, Cursor, and anything that speaks MCP). One command connects it, and your assistant can list your apps, read deploys and logs, diagnose failures, ship fixes, create previews, and manage secrets — with the same sign-in and permissions you have, and guardrails on anything destructive. docs →

Broken database updates can no longer touch your database

Deploys of database apps now rehearse your entire update history on an empty copy before applying anything for real — a broken update fails the deploy with a clear message and your database is untouched. And when an update fails against real data, it rolls back completely and never blocks future deploys: fix it and ship again, no support ticket needed. docs →

Publishing a new version of an app with member sign-in could fail at the very last step of the deploy, with a technical error, even though the build itself succeeded. Public apps were not affected.

The cause was a change in a recent platform update to how the Ghosty platform coordinates the final release step for members-only apps. The fix is now live across the whole platform — no action is needed on your side, and your next deploy will go through normally. If a deploy of a members-only app failed for you in the last few days, simply deploy again.

Ghosty is now White Ghost

Same product, same addresses — the console, sign-in emails, and passkey prompts now carry our new name, White Ghost. Ghosty lives on as our mascot (you'll keep seeing the little ghost, and the ghosty command isn't going anywhere).

Files tab now reflects reality

Fixed: an app whose file-storage setup didn't finish could still show the Files tab in the console, even though no files could be listed or uploaded. The tab now appears only when your app's file storage is actually ready, and it comes back automatically once a retried setup succeeds — including for apps that were already in this half-enabled state.

Adding file storage to an existing app could repeatedly fail with a generic error if the app had an active pull-request preview. The Ghosty platform now handles this combination correctly — file storage can be enabled at any time, previews or not. We also improved the error messages around file storage setup so that if something does go wrong, the message tells you what's happening instead of a generic retry suggestion.

A new home: whiteghost.ai

Ghosty now lives at whiteghost.ai. Old links keep working — they bring you straight to the new address. If you sign in with a passkey, add a fresh one from Settings after your first email-link sign-in: passkeys are tied to the web address where they were created, so ones from the old address no longer work. The console shows a reminder until you do. docs →

The Ghosty CLI signs in at the new address

As part of our move to whiteghost.ai, the Ghosty CLI now opens console.whiteghost.ai when you run ghosty login. Upgrade with:

npm i -g ghosty-cli

Older CLI versions keep working — the previous address continues to reach us — but we recommend upgrading when convenient. Nothing else changes: same ghosty command, same workflow.

Your apps can now react to each other

When something happens in one app, connected apps hear about it — in order, reliably, and only where you've approved the connection.

Ask the assistant building your app to wire it up — "when the orders app gets a new order, update my dashboard" — or to announce this app's own moments to the rest of your workspace. Approvals work exactly like connection calls: a workspace owner or admin approves each one from the console, and revoking stops deliveries immediately. docs →

See how your company works together

The new Company map shows your apps and every connection between them — live, and drawn entirely from what you've approved.

• Open Map in your company workspace: your apps sit at the center, the outside services they use around them, and every approved connection drawn between them in plain language. A dashed line is a request still waiting for approval.
• Select any app to see what it's for, what it can do, and how connected it is. Select a connection to see exactly what flows ("Prediktia reads field visits from VM Wizard"), whether it's active, and its last 7 days of activity.
• Owners and admins can act right there: approve a pending request and watch the line go solid, or revoke a connection on the spot.
• If an update between two apps couldn't be delivered, the connection shows it plainly — with the details one tap away.

Nothing appears on the map that your workspace didn't say yes to. docs →

Connect your assistant to your company

Give Claude (or any assistant) a key to exactly the parts of your company you choose — ask questions, get real answers from your apps, and revoke access any time.

• In your company Settings, the new AI assistants section connects an assistant in one step: name it, and you get its access key — shown exactly once — with ready-to-paste setup for Claude Code and the Anthropic API.
• Then choose precisely what it can use: every app lists what it offers in plain language, and the assistant gets nothing you don't tick. You can change the selection whenever you like.
• Your connected assistants appear on the Company map alongside your apps, with every approval drawn as a connection — so what your assistant can reach is never a mystery.
• One tap revokes an assistant: its key stops working immediately, everywhere.

Nothing is shared with an assistant that a workspace owner or admin didn't approve. docs →

Your apps now describe what they can do

Every app in your workspace can now carry a short, living description of what it's for and what it can do — written next to its code and updated automatically every time the app publishes.

• Open any app and the new "What this app can do" card on its Overview shows the app's purpose and its capabilities, each in plain language, with a note of when they last updated.
• On company workspaces, the Apps directory now shows each app's purpose on its card, and search matches capability names too — so you can find "which app handles invoices" without opening a repo.
• Your assistants read the same inventory, so they know what already exists before building something new — they work smarter together.

Nothing to set up: apps that haven't described themselves yet simply show a gentle hint until their next publish. docs →

Connect your apps — with your approval

Your apps can now share what they do with each other: an assistant requests the connection, you approve it in one tap, and information flows only where you've said yes.

• Requests land on your company home as a Pending connections card — each one in plain language ("Prediktia wants to read field visits from VM Wizard"), with Approve and Decline right there. Only workspace owners and admins decide.
• Every app's Overview now shows its Connections — what it shares with, and receives from, your other apps, each marked active or pending. Owners and admins can revoke a connection at any time; apps using it stop receiving that information immediately.
• Connections are protected: publishing a change that would break one is stopped with a plain explanation, so connected apps never silently lose something they depend on.

Nothing is shared by default — every connection exists because someone in your workspace said yes. docs →

Creating an app now takes just a few answers: a name, a web address, and who can use it. New is an optional "What should it do?" box — describe what you want in your own words, and your app's assistant reads it and starts building from it in your very first session.

We also removed the "What kind of app is it?" question. You no longer have to guess at a technical choice up front — the Ghosty platform picks the right setup for you automatically. docs →

Company onboarding is now three steps

Creating a company workspace is down to the essentials: name it, connect your GitHub organization, submit. Design decisions are gone from onboarding entirely — your apps look good from the start, and design is something you refine later, on your own terms. docs →

You always know what's happening

After you submit, the console shows your workspace being built, step by step — and you don't have to watch. You get an email confirming we're setting things up, and another the moment your workspace is live, with a link to sign in. Setup usually finishes within the hour, and while it runs you can already invite your team.

A design guide your AI assistant follows

Companies can now keep a design guide: a plain-language document with your brand's rules — colors, voice, spacing, links to logos and fonts — in Settings → Company design system. When anyone on your team builds with an AI assistant, the assistant asks whether the app should follow the company design system and pulls the latest guide with the new ghosty design command. docs →

New apps look better out of the box

Fresh apps now start with Ghosty's clean house look and a modern, ready-to-use component kit — buttons, cards, dialogs and forms your assistant can build with immediately, and that restyle automatically when you use the app's Designer.

If your app enabled file storage after it was created, the Files tab in the console could show an empty state even though your app was storing files just fine. That's fixed — the Ghosty platform now keeps your app's catalog entry in sync whenever your app's configuration is applied, so the Files tab always reflects what your app has stored. Your files themselves were never affected. docs →

The CLI now signs in at console.getghosty.dev. ghosty login (0.19.0) opens the console at its own address, console.getghosty.dev, instead of going through getghosty.dev. Nothing to do if you're on an older version: existing installs keep working — sign-in requests to the old address are forwarded automatically, so there's no forced upgrade. The GHOSTY_CONSOLE_URL override is unchanged.

This release also includes reliability improvements to the Ghosty platform behind the scenes. See signing in for the updated sign-in details.

Sign-in links now survive company email security

Many company mailboxes run security tools that open every link in every email the moment it arrives. Ghosty's sign-in links work exactly once — so those tools were using them up before anyone could click, leaving some people (especially on corporate email) stuck at "this link was already used". Sign-in links now land on a small Finish signing in page, and the link isn't spent until you press the button. Scanners can look all they want; your link waits for you. This applies everywhere you sign in with email — the console and the command line. docs →

GitHub connections bind to the right account

On personal workspaces, connecting GitHub could silently latch onto a GitHub organization instead of your personal account, which later broke app creation in ways that were hard to trace. The connect flow now guides you to install on your personal account and clearly rejects a mismatched choice, so what you connect is what your apps use.

Sturdier account removal

Retrying a failed account removal now converges in a single click — previously each retry could advance only one step at a time. Removals are also reported more precisely along the way.

Sessions that keep up with you

Signing in now lasts 7 days instead of 24 hours, and staying active keeps your session fresh — daily users effectively never get signed out mid-work. When a session does expire, you no longer hit a confusing error: the console now takes you straight back to the sign-in page, and once you're signed in again it returns you to the exact page you were on.

Full account removal

We can now remove an account from the Ghosty platform completely on request: every app is taken down, custom domains are released, and all sign-in access and stored account data are purged. Removal is cleanup, not a ban — the same email is free to sign up again afterward. If you'd like an account removed, contact us.

Your www visitors, covered

Most people type www. in front of a domain — but if only the bare domain is connected to your app, those visitors hit a dead end. Now, when you connect a domain like yourdomain.com to an app, Ghosty offers to connect www.yourdomain.com at the same time with a pre-checked option. One click, both addresses. The www connection is independent, so you can remove or repoint it separately at any time. docs →

"Still connecting…" now tells you why

Waiting on a domain that never comes online usually means one thing: a DNS record that was never created. The domain page now tells the difference between a record that exists but hasn't taken effect yet and one that's missing entirely — and when it's missing, it shows the exact record to add at your domain provider, so you can fix it in one visit instead of guessing. docs →

App creation shrugs off temporary hiccups

Very occasionally, a brand-new app could show a red failure during setup even though nothing was really wrong — a piece of the platform was simply asked for before it had finished getting ready. Setup now detects that situation and quietly retries until it clears, so those false alarms are gone. And on the rare occasion something genuinely does fail, the message you see is now written in plain language and tells you what to do next — while the details reach our team automatically so we're already looking into it.

Creating an app used to end with a wait: the wizard held you on the progress screen while the first version built and launched — usually a couple of minutes — before showing you the handoff prompt and links. That wait is gone.

Setup completes as soon as there's something to work on. The moment your app's code and workspace are ready, you get the handoff prompt, the repository link, and everything you need to start building — the first version finishes launching in the background, and the page flips to your app's live address on its own.

The app page keeps you in the loop. While the first version is launching, your app's page shows exactly that. And if a first launch ever fails, the page says so and gives you a working Try again button that picks up where things left off — no more new apps stuck saying "needs attention" after a rough start.

The biggest piece first: connected services don't just answer your app anymore — they can notify it. Enable events for an attached service (Stripe, for example) and Ghosty gives you an events address to paste into that service's dashboard. From then on, every notification is checked for authenticity and delivered to your app's code — a checkout completing, a subscription changing — with unverifiable deliveries dropped before they ever reach you, and a Recent-events list so you can see what arrived. Scaffolded apps include a ready-made handler: register what you care about and the platform does the rest.

The Ghosty command line now keeps itself current. It quietly checks for newer versions, tells your app's coding assistant in a way it can act on (so updates just happen — you're never asked to run anything), and the platform can gently retire versions that are too old to serve safely.

Custom domains got sturdier: a domain's verification window is now visible while it's counting down, a domain that verifies near the deadline is honored rather than dropped, and if one does expire you can reclaim it yourself immediately — no support round-trip.

And a fix worth celebrating: new apps no longer show a failed first deploy in their history. One deploy, the right one, from the first minute.

Receiving events → · Command line updates → · Custom domains →

Setting up a company on Ghosty no longer asks who's allowed to sign in. Create your workspace, then invite people from the Team page: add a teammate's email and they can sign in right away — any address, work or personal — and they get a note letting them know. Remove someone and their access ends immediately. No domain lists to maintain, no one locked out of their own workspace.

Apps gain a matching superpower: a new "Workspace members" access mode. Pick it when creating an app and every visitor must sign in as a member of your workspace — a branded sign-in with their email, nothing to configure in your code. Removing someone from the team closes their app access too, and a "Sign everyone out" button in the app's settings resets all sessions at once. The existing public, invite-link, and build-your-own modes are unchanged.

Also new in the catalog: Melonn — connect the Sellers API once and your apps can manage orders, products, stock and returns without handling credentials.

How teams work → · The four access modes → · Browse integrations →

Apps that store files no longer keep them out of sight. Every app page now has a Files tab: browse folders, preview images, PDFs and text right in the console, download anything, and delete what shouldn't be there. Files stay private to the app — viewing and downloading happen through your signed-in console session only, never through public links.

The integrations catalog also grows from 18 to 25 services. New this release: Algolia and Pinecone for search, Firecrawl and Exa for AI agents that read the web, Mapbox for maps, Postmark for email, and Telegram for bots. Same model as always — connect once, attach to any app, and the credential never appears in your code.

Read the file storage guide → · Browse the integrations →

Every app's Integrations tab now shows what it's actually doing with the services you've connected: how many calls it made to each one over the last 7 or 30 days, how fast they were, and whether any failed. No agents to install, no dashboards to configure — if your app talks to OpenAI, Stripe, or any other connected service, the numbers are already there.

Alongside the visibility, the Ghosty platform now applies sensible fair-use limits per app and service, so one runaway loop can't exhaust a shared account or your provider bill. Apps that hit a limit get a clear signal and can simply retry a moment later; everything else keeps flowing untouched.

This release also lays groundwork you'll see surface soon: the platform can now look inside an app's file storage, powering an upcoming Files view of everything your app has stored.

Read the integrations guide →

Your Ghosty apps can now talk to the outside world without you ever handling a credential in code. Connect a service once from the console — OpenAI, Anthropic, Stripe, Resend, Twilio, Slack, GitHub, Notion and ten more — and attach it to any of your apps with a click.

The key you paste is encrypted immediately and never shown again, not even to you. Your app calls the service through the Ghosty platform, which adds the real credential on the way out — so nothing secret ever lives in your repository, your environment files, or your deploys. Detach or rotate at any time and access stops on the next call, no redeploy needed.

On company plans, a connection can be shared with the whole team: one Stripe account, every app on it, revocable by whoever created it.

Read the integrations guide →