Changelog

Documentation site and content release notes.

2026-10-14 — Who can reach your Service

Added

• Who can reach your Service: every Service is public, and Groundfloor doesn't sign anyone in before passing on a request. Choose between open to everyone, the app's own logins, or checking the signed-in user's token in a Shell app's backend. Covers finding your issuer and client ID, what to check (signature, iss, exp, azp), where roles are (realm_access.roles), FastAPI and Node.js examples, and CORS for your Shell site.
• Running an off-the-shelf app: the port, database, uploads, sessions and admin pages to check before running software you didn't write.

Changed

• The secrets example passes environment_id=$GROUNDFLOOR_ENVIRONMENT_ID to choose which environment's secrets to read. Without it a Service reads the workspace's dev secrets, even in production.
• Sign-in and users lists the iss, azp and realm_access.roles claims.
• Example: run WordPress: start.sh reads the password for its own environment, keeps the M2M credentials out of command-line arguments and out of WordPress, and stops if it can't read the password. Complete the WordPress installer as soon as the first deploy finishes.
• Groundfloor MCP 0.2.4: its guidance now matches these changes. A new service-access guide (docs_get service-access) tells agents every Service is public, what each kind of Service needs (open to everyone, its own logins, or a Shell app backend), and what a Shell app's backend must check in the user's token (signature, iss, exp, azp, and the organization claim when one backend serves several companies). The Coderunner guide passes environment_id when reading secrets and says it only chooses which environment's value is returned; it isn't an access boundary. MCP 0.2.3's example reads secrets without environment_id, so code written from it reads the dev values. Upgrade with npm i -g @groundfloorcloud/mcp@latest.

Known issues

• Every app on your Shell site, including apps you didn't write, can get the signed-in user's token and call your backends as that user, and a token from one of your apps is accepted by your other apps' backends in the workspace. Only install apps you trust, and check roles for anything sensitive. Per-app tokens are coming soon.

2026-10-14 — Support requests in the Client Portal

Added

• Support requests. Open a request from Help & support in the Client Portal, choose a topic (technical, billing, account and access, security or something else) and how urgent it is (Urgent means production is down), and follow the conversation with Groundfloor on the request's page. Statuses: Open, Waiting for Groundfloor, Waiting for you, Resolved (reply to reopen) and Closed (final). Email is still available. See Support requests in the Client Portal.
• Who sees a request depends on its topic: the person who opened it, Owners (all requests), Admins (all but security reports) and Billing admins (billing requests). Writers, Members and Partners see their own. Security reports are visible only to the person who opened them and the Owners. See Who sees a request.
• Emails when you open a request, when Groundfloor replies and when Groundfloor resolves it. They contain only the request number and a link, never the subject or the message text, and go to the person who opened the request, or the Owners if that person has left.
• Open a support request next to Client Portal errors that tell you to contact support, with the error's details filled in for you to check.
• If you paste something that looks like a password, key or token, you're warned. Rotate it and ask Groundfloor to redact it; redaction doesn't remove it from backups. See If you shared a secret by mistake.
• Limits: about 5 new requests an hour per person, and 20 a day and 25 open at once per organization.
• Support API: GET and POST /v1/organizations/{organization_id}/support/tickets, and …/{ticket_id}, …/messages, …/resolve and …/close, for team members' tokens.

2026-10-14 — Support page

Added

• Support: how to contact Groundfloor support by email, our hours, what to include (organization ID, workspace, the exact error), what never to send, and the Security and Billing subject lines. Pages that say "contact support" now link to it.

2026-10-14 — App user invitations, organization roles, billing statements

Added

• App user invitations you can follow up. On App authentication → Users, an Invited user's row now says whether the invitation email was sent, wasn't sent (with the reason), or wasn't confirmed. If it didn't arrive, Resend it (once a minute, up to 5 times a day), give them a Temp password to share privately, or Copy link to send a one-time invite link, valid for 24 hours, where they choose their own password. See If the invitation doesn't arrive. API: new user fields email_attempted_at, password_change_required, temporary_password_set_at and invite_link_expires_at, and new resend-invite, temporary-password and invite-link routes; see the Workspace sign-in API.
• Add user can generate the temporary password for you, shown once (generate_password in the API). Invite and add take an optional app_id, so the email's sign-in link opens that app.
• Billing statements: once Groundfloor issues a monthly statement, Owners, Admins and Billing admins can see it on the organization's page and download it as CSV. API: GET /v1/accounts/{id}/billing-statements and the plan catalogue, GET /v1/billing/plans; see the Billing API.
• Databases always lists Shared PostgreSQL first, and shows whether each managed database is connected to the data API, with Retry when it isn't. New managed databases start with a daily backup schedule, kept 30 days, where backups are available. See Managed databases.
• A standalone app whose main Service failed to deploy now says so on its page, and its address answers 503. The Coderunner status API returns deployment_status and deployment_status_message. See When a deployment fails.
• Delete an organization is now described in the guides.

Changed

• Organization roles. An organization now has Admin and Writer roles too. Billing admin is billing only: billing, statements and the billing contact, with no workspace access and no member management. Organization Owners and Admins manage members and workspaces and have Admin access in every workspace. Only an Owner can delete an organization or cancel its deletion. This replaces the 2026-10-08 description. See Team and roles.
• Workspace export is limited to workspace Owners and Admins, and organization Owners and Admins, and the file leaves out internal platform details.
• Team lists only your team. Your app's users never appear there, and their sign-in tokens work only on the routes an app needs (apps, Data Vault records, Files and flag values); every other route returns 403. See App user tokens.
• Inviting or adding an app user who can already sign in is refused (409); send a password reset instead. Invitation links in emails now last 72 hours. email_sent can be null when delivery is unconfirmed, and email_skipped_reason is one of smtp_not_configured, send_failed, delivery_unconfirmed or not_requested; keycloak_smtp_missing is no longer returned.
• Team Add member sends invitation details by default (never the password); you can turn it off.
• An organization deletion can be cancelled until it starts, even after the scheduled date.
• Secret-like values are removed from activity log details when you read or export them.
• Data Vault API: count takes a filter; a record update returns the full stored record; schema updates add new fields and can turn on unique; a grant to a role that doesn't exist is 422. See the Data Vault API.
• The default app set with PUT …/default-app isn't used by the Shell site yet; the docs said it was.
• Groundfloor is invite-only: creating an organization yourself is off unless Groundfloor turns it on. GET /v1/me/capabilities tells you whether you can.
• Groundfloor MCP 0.2.3: its guidance now matches these changes. The App authentication guide tells agents to check email_sent and email_skipped_reason before saying an invitation was delivered, and to offer Resend, a temporary password or a one-time invite link when it wasn't. It also covers the 409 for people who can already sign in, app_id, and the routes app users' tokens can call. billing_summary is readable by organization Owners, Admins and Billing admins. The databases guide covers Shared PostgreSQL on the Databases page, dataplane_status with Retry, and the default backup schedule. The Coderunner guide covers deployment_status and the 503 for failed deployments, and the flags guide says any App authentication role can read runtime flags. MCP 0.2.2 still says only Owners and Billing admins can read billing and doesn't describe the invitation fallbacks. Upgrade with npm i -g @groundfloorcloud/mcp@latest.

2026-10-13 — gf CLI 0.2.1: gf deploy reports failed deployments

Upgrade with npm i -g @groundfloorcloud/cli@latest.

Changed

• gf deploy exits non-zero when the new deployment fails. It now follows the deployment it just created. If that deployment fails or is deleted, gf deploy exits with a non-zero status and the reason. CLI 0.2.0 and earlier exited 0 and printed "Deployment completed" while the previous version kept serving. Scripts and CI pipelines that relied on exit 0 now see the failure. See gf CLI — CI pipelines.
• gf deploy -c <coderunner> asks before dropping environment variables. Groundfloor doesn't keep variable values, so each deploy must send them again. When a deploy to an existing Coderunner wouldn't send variables the previous deployment had, gf deploy lists their names and, on a terminal, asks "Deploy anyway and clear these variables?". The default is No, which stops before anything is uploaded; --yes skips the question. Without a terminal, such as in CI, it prints the warning and deploys anyway. See Confirmations.

2026-10-13 — Sign-in email works by default

Added

• Your app users' sign-in emails (invitations, password resets and email verification) are now sent by Groundfloor email in every workspace, with nothing to set up. They come from a Groundfloor no-reply address, with your organization's name as the sender. See Sign-in email.
• Branding → Email sending lets you choose Your own email server instead, and Send test email sends a test to your own address. API: mail.mode on the workspace sign-in API and POST /v1/workspaces/{workspace_id}/auth/mail/test.

Changed

• If your own email server fails, the email isn't sent; Groundfloor email isn't used as a fallback. Switching back to Groundfloor email removes your saved server settings and password.
• Groundfloor MCP 0.2.2: its App authentication guide now tells agents that invitation and password-reset emails work by default through Groundfloor email, and that your own email server is set under Branding → Email sending. It warns that saving email settings without a server host deletes your saved server settings, and it corrects Add user: the user gets an email with their sign-in details, never the password. MCP 0.2.1 still says invitation emails need Branding set up and that Add user sends no email. Upgrade with npm i -g @groundfloorcloud/mcp@latest.

2026-10-13 — Apps identify users by sub

Changed

• Apps should identify users by the token's sub claim; external_user_id carries the same value on Groundfloor sign-in. See Know who the user is.

2026-10-13 — App users' Data Vault access is per collection

Known issues

• A grant to your app's users covers a whole Data Vault collection: whoever can read it sees every record, and write and delete apply to every record. Don't grant app roles a collection that holds other users' private records; have your backend read it with an M2M client and return only the signed-in user's records. See Who can use a collection. Per-record access for app users is planned.

2026-10-12 — App role admin is granted like any other role

Changed

• The built-in admin role for your app's users is now a role like any other. It reaches a Data Vault collection, Files or an app only through a grant, and its grants are listed and editable on Site access. Existing collections, Files and restricted apps are given explicit admin grants, so admins keep the access they had.
• New collections start with admin → delete, and new workspaces start with admin → write on Files. You can change or remove these grants.
• Check your scripts: every Access PUT (Access, collection Access, Files, app access) saves the grant list exactly as sent. If you leave admin out, its grant is removed and admins lose that access. Read the current grants first and send them back with your change.
• An app is open to the whole workspace only when every role, admin included, can launch it.
• Only your team can read or change Access. App users get 403 on these routes, whatever their role, admin included.
• When you switch an app from open to the whole workspace to restricted, admin is added to the roles that can launch it. You can remove it afterwards.
• Groundfloor MCP 0.2.1: its guidance now tells agents that admin is granted like any other role, and that every Access PUT replaces the whole list, so agents keep admin and the existing grants. MCP 0.2.0 still says admin has access automatically. Upgrade with npm i -g @groundfloorcloud/mcp@latest.

2026-10-10 — gf CLI 0.2.0 and Groundfloor MCP 0.2.0

Upgrade both with npm i -g @groundfloorcloud/cli@latest @groundfloorcloud/mcp@latest.

Added

• gf usage [--account <id>] [--since-days <n>] [--json]: your organization's plan usage and billing estimate, read-only. The account is the organization that owns the workspace, not the workspace. See quotas and limits.
• GROUNDFLOOR_TOKEN for CI and containers: set it to a token, for example from gf m2m token, and gf uses it instead of a saved sign-in. See gf CLI — CI pipelines.
• Groundfloor MCP: quota_get (plan usage against limits) and billing_summary (spend; Owners and Billing admins only) tools; docs_get id authentication (app authentication); and Coderunner runtime limits in docs_get id coderunner-runtime.

Changed

• Custom domains work again. CLI 0.1.13 and MCP 0.1.16 called the Coderunner domain routes, which always return 400 "Custom domains are available on Apps, not standalone coderunners." Domains belong to standalone apps: gf domains ls|add|rm|verify --app <id|slug>. The MCP domains_list tool takes app_id, or the app's main Coderunner as coderunner_id.
• Breaking (CLI): gf domains --coderunner / -c is removed; use --app. To give a Service a domain, wrap it in an app first: gf apps create --kind standalone --primary-coderunner <id>.
• Breaking (CLI): without a terminal (CI, agents), gf deploy no longer uses the workspace saved with gf workspaces use; pass -w <workspace-id> or set GROUNDFLOOR_WORKSPACE_ID. On a terminal it shows the saved workspace and asks you to confirm.
• Breaking (CLI): when gf deploy would update an existing Coderunner with the same name, it asks you to confirm. Without a terminal, pass -y / --yes.
• Breaking (CLI): gf coderunner cancel-deployment (alias delete-deployment) deletes the deployment; if it is the live one, the Coderunner goes offline. It asks you to confirm on a terminal and needs --yes without one.
• Breaking (MCP): coderunner_cancel_deployment needs a deployment_id and acts only on the workspace you selected. It is marked destructive; every other tool only reads. The MCP now needs @modelcontextprotocol/sdk 1.23 or later.
• gf deploy warns when environment variables set on the previous deployment are not sent again (they are dropped), and when --app-id is ignored because an existing Coderunner is reused.
• gf coderunner logs rejects --limit above 1000 and --since-seconds above 604800 (7 days) instead of sending a request the API refuses.
• gf workspaces use checks that the workspace exists and that you can access it.
• ~/.groundfloor/config.json is now readable only by you (chmod 600).
• Groundfloor MCP: the Data Vault guide describes bounded $text search.
• Groundfloor MCP: the unprefixed environment variables CP_API, WORKSPACE_ID and TOKEN are deprecated. Use GROUNDFLOOR_API_URL, GROUNDFLOOR_WORKSPACE_ID and GROUNDFLOOR_TOKEN.
• The LLM Gateway is shown as Coming soon in the Client Portal. Its page now says so.

2026-10-08 — Delete a workspace, Freeze is now a suspend

Added

• Delete a workspace: a workspace Owner can schedule a workspace for permanent deletion in 30 days from its Danger zone, restore it before the date, or (where enabled) use Delete now. The page covers what happens during the window, who is emailed, and what is and isn't erased yet.

Changed

• The Freeze action in the Client Portal is replaced by Delete workspace. Freezing a workspace no longer starts a deletion countdown: a frozen workspace is a suspension with no deletion date, and nothing is erased. Workspaces and the Workspaces API are updated to match.

2026-10-08 — Guide review fixes

Changed

• AI agents and MCP: the MCP is not read-only. coderunner_cancel_deployment deletes a deployment, so don't auto-approve it. This corrects the 2026-08-30 note that the MCP is inspect and docs only. The tool table now lists every tool.
• Team and roles: an organization has Owner, Billing admin, Member and Partner roles; Admin and Writer exist only in a workspace. Added what organization roles inherit in workspaces.
• Quotas and limits: plan limits are provisional and only workspace count and file storage are enforced. LLM Gateway usage does not count against a quota. Added the upload and per-workspace database limits.
• Configuration and secrets and Secrets: deploy variables with credential-shaped names are rejected, not dropped. Copying secrets into a deployment with --secret is off platform-wide; read secrets at runtime.
• LLM Gateway and its API: marked Coming soon. The gateway is not part of the current release, so the pages now describe it as planned, and the Billing and Quota pages note that the AI and LLM compute unit figures stay at 0.
• Functions and Python: the CLI also detects Python from pyproject.toml.
• Custom domains belong to apps, not Coderunners: add them on an app's Domains tab. The Coderunner domain routes return 400; see the 2026-10-10 entry for gf domains --app.

Added

• Usage and billing, Workload identities and Security and isolation.

2026-10-04 — gf deploy checks for handler.js

Changed

• gf CLI 0.1.13: gf deploy now checks that a Node.js function, job or schedule has a handler.js in the project root that exports handler (or a package.json "main" that points to an existing file). scripts.start is now required only for services, and for Dockerfiles that run npm start. A Node.js function, job or schedule that has only scripts.start and no handler.js now fails right away with a clear message, instead of deploying a revision that crash-loops. Upgrade with npm i -g @groundfloorcloud/cli@latest. See Node.js.
• Groundfloor MCP 0.1.16: the Coderunner guide, runtime docs and playbook describe the same rule: handler.js for functions, jobs and schedules, scripts.start only for services. They no longer carry the earlier known-issue wording.

2026-10-01 — Reorganized docs, Coderunner corrections

Changed

• The docs are now organized by what you want to do: Getting Started, Deploy, Apps, Data, Configure, Access & Security, Observe, Organization and Developer Tools. The API reference has its own sidebar tab. Old links redirect to the new pages.
• Internal platform architecture pages were removed; they described how Groundfloor is built rather than how to use it.
• Accounts are now called organizations everywhere in the docs, matching the Client Portal. The Organizations API uses /v1/organizations; /v1/accounts paths keep working.
• New Troubleshooting and FAQ and Glossary pages.
• Rewritten API reference: a single overview (base URL, first request, errors, every resource), an authentication page built around the three kinds of token, plain wording on every page, and a sidebar grouped like the guides. Old links to the API introduction redirect to the overview.
• Rewritten Organization and Developer Tools: workspaces, quotas and limits, the gf CLI reference, and AI agents and MCP, which now includes the Coderunner agent rules.
• Rewritten Access & Security and Observe: team and roles, app authentication, site access, M2M tokens, your profile and the activity log.
• Rewritten Data and Configure sections: a data overview, managed databases (including the secret names that hold each database's credentials), Data Vault, files, environments, secrets, feature flags and the LLM Gateway.
• Rewritten Apps section: standalone apps, and a new Shell apps guide — build your first, sign-in and users, data, files, feature flags, secrets and backends, styling, local development and troubleshooting.
• Rewritten Deploy section: a page each for Functions, Jobs, Schedules and Services, plus deploying and versions, configuration and secrets, logs and troubleshooting, and language references for Node.js, Python, .NET, Go and — new — Rust.
• Writers can create, deploy and run Coderunners; the roles table said otherwise.
• New Getting Started guides: what Groundfloor is, a quick start that deploys your first function, core concepts, and a tour of the Client Portal.
• Function, job and schedule code is a handler only: no HTTP server or port. Only a service runs its own server. Node.js projects still include "scripts": { "start": "node handler.js" } in package.json (Coderunner). Resolved in CLI 0.1.13: a function, job or schedule now needs handler.js, not scripts.start (2026-10-04).
• Secrets: the recommended way to give a workload a secret is to read it from the Secrets API at runtime with an M2M client that has Read secrets, not to pass it at deploy time. This keeps secrets out of the deployment's configuration and lets you rotate them in one place (Secrets in a workload).
• Supported languages are Node.js, Python, .NET and Go. dotnet-script is no longer listed.
• The Service Dockerfile example uses node:22-alpine.

2026-09-26 — Feature flags at runtime, gf flags

Added

• Feature flags: GET /v1/workspaces/{id}/flags/runtime, a compact {key: value} read for apps. Shell apps call it with the end-user JWT (site role → workspace read); Coderunners call it with an M2M token. Weak ETag / If-None-Match → 304. See Feature Flags — Read flags at runtime.
• Shell: window.__GF_ENVIRONMENT_ID__ and window.__GF_APP_ID__ for the mounted app, and environment_id on the public app bootstrap (Shell: Feature flags).
• Coderunner deploys inject GROUNDFLOOR_ENVIRONMENT_ID (the Coderunner's bound environment).
• Starter kit: src/lib/flags.ts with useFlag / useFlags / listFlags / getFlag.
• gf flags ls|get|set|rm|compare|promote with -e <environment id or name>.
• Groundfloor MCP: docs_get ids feature-flags and flags-api, a flags_list tool, and environments + feature_flags_howto (including the default environment) in workspace_context.
• Every /flags operation in /openapi.json now documents default-environment resolution, key format, value validation, permissions and errors (Feature Flags API).

Changed

• M2M tokens are read-only on flags: PUT, DELETE and promote return 403. Previously an M2M write was applied but reported 403 and left no audit entry.
• Flag keys compare, promote and runtime are reserved (400 on PUT).
• The API now enforces PostgreSQL-only: creating a dedicated database with another engine is 400, and Vault ?connection= must be postgresql or one of the workspace's dedicated PostgreSQL databases (400 otherwise). A collection created without an engine now goes to PostgreSQL (previously ArangoDB).
• Docs, the Groundfloor MCP and the Shell starter kit now describe databases as PostgreSQL-only (Managed Databases, Data Vault): shared PostgreSQL is ready through Dataplane, and a dedicated PostgreSQL is what you can deploy. They no longer offer ArangoDB, Redis, ClickHouse or Qdrant.

2026-09-25 — Data Vault engine fixes, Groundfloor MCP 0.1.13

Added

• Data Vault (Postgres): record fields the schema doesn't declare are kept and returned on read, and filters can target them. They're stored in a reserved gf_extra column, so gf_extra joins id and tenant_id as a reserved field name (400) — see Data Vault API.
• Data Vault (Postgres): array and number field types. unique and indexed on a field are now enforced, scoped to your workspace.

Changed

• Data Vault (Postgres): each workspace's collections are fully separate, so two workspaces can use the same collection name with different fields. JSON, UUID, and timestamp fields are returned on read (previously dropped), and the exists filter works.
• Data Vault (ArangoDB): filtering or fetching by id returns the record (previously always empty). Large collections return complete results and accurate counts (previously cut off at the first 1,000 rows).
• Data Vault (ArangoDB): a record is an edge only with both _from and _to (or in and out). Plain from / to are ordinary fields — previously such records were accepted but never returned. A lone _from or _to is rejected.
• Live record subscriptions apply the same read permissions as REST reads; events for records you can't read are no longer delivered.
• Groundfloor MCP 0.1.13: the Coderunner guide no longer tells agents to ask for deploy-time secret injection to be enabled per workspace. CODERUNNER_INJECT_ENV_SECRETS is a platform-wide setting that is currently off; agents are pointed to reading secrets at runtime via an M2M client with secrets:read (known issue). The inject_secret_keys description in the Coderunners API schema says the same.

2026-09-24 — M2M secrets scope, invitation acceptance, Coderunner run body

Added

• M2M tokens: per-client Read secrets (secrets:read scope). Lets a workload list, compare, and reveal workspace secrets at runtime. Read-only and workspace-wide. See M2M API — Scopes.
• Members & Roles: invitations to new users are Pending until the invitee clicks Accept on the portal banner. API: GET /v1/me/pending-invitations, POST /v1/memberships/{id}/accept / reject. Membership rows now include status.
• Self-service password change: Settings → Password, or POST /v1/me/password.
• Data Vault: collections carry created_by / created_at (list and schema).
• Coderunners API: GET …/{id}/deployment?version_id= returns version_deployment_id.
• Shell: setBreadcrumbLabel bridge for detail-route breadcrumbs (Manifest and routes).
• Shell routes: hidden: true keeps a route out of the sidebar nav while leaving it navigable (Route object).

Changed

• Coderunner run (breaking for direct API callers): POST …/coderunners/{id}/run body is now the event JSON itself, not { "payload": … }. version_id, deployment_id, and deployment_url are query parameters. The gf coderunner run --payload flag is unchanged.
• M2M clients without secrets:read can no longer list secret keys (previously allowed by accident). Secrets writes are always denied to M2M.
• POST …/m2m/token is rate-limited per client (workspace_id + client_id) as well as per IP, both default 20/minute. Cache the token for expires_in; do not mint per request.
• Data Vault: Postgres is the default engine (shared, platform-provisioned). New collections require an explicit engine choice. ArangoDB is still supported. id and tenant_id are reserved field names on Postgres (400).
• Workspaces: hitting the plan's workspace limit returns a readable 409 message naming the plan.
• Secrets docs: reveal requires write (docs previously said read).
• Shell manifests: saving through the Portal or API now keeps route hidden, visibility, and any other route keys. Previously they were dropped on save.
• gf CLI 0.1.10: gf coderunner run --payload sends the event as the request body. 0.1.9 wrapped it as { "payload": … }, so handlers received it nested under payload — upgrade with npm i -g @groundfloorcloud/cli@latest.
• Groundfloor MCP 0.1.12: updated agent guidance for M2M token caching and 429s, Shell breadcrumb labels, and hidden detail routes.

2026-09-21 — Known issue: Coderunner deploy-time secret injection

Known issues

• Coderunner: inject_secret_keys on POST …/deploy returns 422 on every workspace. CODERUNNER_INJECT_ENV_SECRETS was turned off platform-wide on 2026-09-06 to stop database/vault credentials from leaking into workload env by default; it is not currently workspace-scopable. Until it is restored, have the workload fetch secrets itself at runtime via an attached M2M client instead — see Coderunner prerequisites and M2M tokens.

2026-09-12 — Workspace multi-tenant (Tenants)

Added

• Authentication: opt-in Multi-tenant switch (Groundfloor login active) turns on Keycloak Organizations inside gf-ws-{id}. Tenants tab: members, per-tenant SSO, JWT organization claim. Access / Vault / Files / M2M stay workspace-wide.
• Workspace Auth API: GET/POST/PATCH/DELETE …/auth/tenants and members; PUT /auth multi_tenant.enabled (409 if Groundfloor is not active); invite tenant_id; SSO create organization_id.

Changed

• Shell auth modes: keep external_tenant_id as the workspace UUID. Apps read organization for tenant context.

2026-09-11 — Access, M2M tokens, and Groundfloor realm keep/delete

Added

• Access: site roles → Data Vault collections, workspace-wide Files, and Apps launch. Admin is implicit. M2M is not a subject.
• M2M tokens: hashed secret → short Control Plane JWT. Attach on Coderunner or use gf m2m token. Never a Dataplane key. v1 is Team Writer (no collection ACL).
• API reference: Access and M2M, including POST …/m2m/token (unauthenticated client_id + secret → JWT).

Changed

• Authentication: leaving Groundfloor keeps the Keycloak realm (disabled). Explicit Delete Groundfloor login (administer, type workspace name) removes users/SSO/branding after login is off.
• Coderunner / Developers: App authentication is optional. Workloads call Vault/Files with M2M via Control Plane.
• Shell auth modes: BFF uses Control Plane M2M, not Keycloak client_credentials against Dataplane.
• Data Vault, Files, Apps: point at Administer → Access for site grants.

2026-09-08 — Apps and Coderunners without App authentication

Changed

• Authentication: creating Apps or Coderunners does not require workspace site auth. Mode None is valid. Site auth is end-user login only.
• Coderunner: Control Plane mints a Portal-signed management JWT when there is no workspace site issuer. Code Runner verifies GET /v1/public/jwks.json.
• Public / unauthenticated apps: browser never calls /vault, /files, /secrets, or /llm. A server-side BFF uses M2M for vault, files, and LLM. Secrets are injected into that BFF at deploy.

2026-09-01 — Coderunner workload types and deploy rules

Added

• Coderunner: type usage for function, job, schedule, and service (also called Deployment)
• Service/Deployment: root Dockerfile is required; Node packages need scripts.start and must listen on PORT/8080
• Local development against live workspace vault/files/secrets (gf env + gf token)

Changed

• Authentication: Coderunner create requires Groundfloor or External workspace site auth (realm active)
• Agents, Developers, Coderunner overview, and API reference match those packaging and auth rules

2026-08-30 — Groundfloor MCP (@groundfloorcloud/mcp)

Changed

• Agents and Developers: MCP is inspect + docs (workspace_context, docs_get, suggest_cli). Actions stay on gf (login, workspaces use, deploy). Do not paste JWTs into Cursor MCP config.

2026-08-30 — Members Invite/Add + vault collection Access

Added

• Members & Roles: Invite member vs Add member (admin-set password, optional temporary password)
• Authentication: Invite user vs Add user for workspace-site end users
• Data Vault Access — per-collection grants for Shell site roles (admin-only default)
• Agent guide: permission checklist before vault / managed database API calls
• SpiceDB: portal_vault_collection + portal_ws_site_role in the public schema excerpt

Changed

• Customer Portal host documented as console.groundfloor.cloud (*.app.groundfloor.cloud is for deployed apps)
• Vault / Dataplane copy uses instruction language: browse databases with Vault; vault routes are the managed database APIs (Dataplane is the product behind the proxy)
• Memberships API documents password / temporary_password on POST …/members
• Workspace auth API documents POST …/users/add
• ReBAC and portal guides tell agents to suggest collection Access on site-user 403s

2026-08-23 — Portal parity (post-deploy)

Changed

• Members & Roles: portal capability copy, change-role flow, account admin/writer + SpiceDB account->read
• Authentication: custom domain CNAME + automatic TLS; Shell login branding precedence
• Coderunner: environment column; Deployment URL from ExternalEndpoint (hidden for schedules)
• Apps: Link existing helper in the portal
• Data Vault: Control Plane translates shorthand filters/sorts to Dataplane structures
• Public docs use production hosts only (platform / auth / console.groundfloor.cloud; apps on *.app.groundfloor.cloud)
• Coderunners API: run-scoped JWT on invoke; workspace-site tokens accepted

2026-08-21 — gf login

Changed

• Developers and agent guides document gf login against production Control Plane / IdPlane

2026-08-21 — Agent deploy + CLI app publish

Added

• Deploy with agents — which path to use (Coderunner vs Shell vs standalone)
• Coderunner agents — workload-only reminder for MCP / gf deploy

Changed

• Developers, Apps, and Coderunner guides point agents at gf deploy for workloads and gf apps create / gf apps publish for Shell remotes
• Shell getting started notes production hosts and CLI publish

2026-08-09 — Roles clarity + customer API coverage + IdPlane

Added

• API reference: Apps, Coderunners, Environments, Feature flags, LLM, Managed databases, Audit, Process log, Quotas, Workspace auth
• Explicit three role planes across ReBAC, Members & Roles, Authentication, Core concepts, Memberships API (platform vs environment deployer vs app end-user)
• Customer Portal guides: Databases, Feature flags, Authentication, Developers

Changed

• Identity branding: public docs use IdPlane (auth.groundfloor.cloud) — no vendor IdP names
• Renamed Control Plane guide to IdPlane integration
• API introduction indexes all customer guides; /v1/admin/* staff-only and not public docs
• Refreshed Apps, Coderunner, Environment Promotion, LLM Gateway, and Coderunner integration overview for shipped UI (D-061)

2026-06-17 — Pico deployment

Added

• Kubernetes manifests and ./deploy/apply.sh for Pico (kubectl-fh, namespace webapps)
• Next.js output: 'standalone' for container deployment
• Production ingress at docs.groundfloor.cloud

Changed

• Primary hosting documented as Pico (not Vercel)
• Build uses next build --webpack for production and CI

2026-06-17 — Phase 4 (Control Plane + integrations)

Added

• Control Plane: Identity & auth, ReBAC, SpiceDB schema, lifecycle, observability, architecture decisions
• Integrations: Coderunner overview + API reference, Dataplane authz brief
• UI screenshot checklist (docs/implementation/UI_SCREENSHOTS.md)

Changed

• Control Plane sidebar expanded from overview stub to full section
• Integrations index links Coderunner and Dataplane

2026-06-17 — Phase 3 (API reference)

Added

• API reference: Authentication, Accounts, Workspaces, Memberships, Data Vault, Files, Secrets
• Changelog page

Changed

• API introduction links to full endpoint guides

2026-06-17 — Phase 2 (portal integration)

Added

• Customer Portal in-app Documentation links (NEXT_PUBLIC_DOCS_URL)
• Docs header product navigation, screenshot asset folder, deploy manifests

2026-06-15 — Phase 1 (Customer Portal guides)

Added

• Customer Portal pillar guides (10 live + 4 stubs)
• Getting Started, Shell integration migration
• Next.js + Fumadocs site scaffold

2026-06-15 — Planning

Added

• Tech stack decision, information architecture, migration plan
• Site development and release guides