Changelog

Notable changes to Dibbla. Subscribe to the RSS feed if you'd rather pull than push.

2026-10-08

Secrets are write-only

A secret’s value now goes one way: into Dibbla, and from there only into your running app. No Dibbla API, CLI command or MCP tool returns it, and a plain env var can no longer stand in for one.

• dibbla secrets get is gone — it explains why and exits 1 — and dibbla export writes secrets by name only; --include-secrets is refused.
• dibbla env pull writes the plain variables with their values and each secret as an empty line for a development value of your own. A line you filled in is never overwritten.
• dibbla secrets set asks for the value at a hidden prompt. A value typed on the command line still works, with a warning.
• dibbla secrets request prints a link to a signed-in Dibbla page where the value is typed — what an AI assistant runs instead of asking you to paste a key.
• A plain env var that should have been a secret is promoted, with a new value you enter on a Dibbla page: dibbla env promote, Make secret in the console’s environment editor, or platform_secret_write action=promote on the platform connector. The env var is removed from the whole app and the app restarts.
• An env var named like one of the app’s secrets is refused, and one whose name or value looks like a secret is refused unless a person confirms it is not one. In dibbla.yaml such an entry is a warning for a person — also on a deploy from a linked folder — and a refusal for an AI assistant’s deploy.
• Logs and build output show [secret NAME] where one of the app’s secret values would have appeared.
• dibbla storage credentials no longer prints the app’s keys for a bucket.

See Env vars and secrets and dibbla secrets.

2026-09-30

E-mails when the trial has ended

Owners and admins now also get an e-mail the day their free trial ends — the apps keep running exactly as they are, deploying is paused until the organization upgrades — and one more a week later if it is still on the trial, asking whether anything is in the way. Replies reach a person, and nothing follows after that. See Reminders by e-mail.

Checks on apps behind a login

Application checks now test apps that have require_login or an access policy. The login page no longer answers in the app’s place, so you do not have to make an app public to monitor it. The check comes in as a visible, read-only machine identity (X-User-Kind: application-check). Its credential is valid only for that app and that run. See Apps behind a login.

2026-09-27

Trial reminders by e-mail

Owners and admins of an organization on the free trial now get a short e-mail seven days before the trial ends and another the day before, with the end date and the link to upgrade — your apps keep running either way. Replies reach a person, and the mail’s unsubscribe link stops further reminders. See Reminders by e-mail.

dibbla upgrade — the payment link in your terminal

dibbla upgrade prints a Stripe Checkout link that moves your organization from its free trial to Business, the same link the console and a connected agent give you. --open opens it in your browser; --json hands it to a script as checkout_url. Only an owner or admin gets a link — everyone else is told who can upgrade. dibbla status names the command under every trial’s Plan: line, and a deploy refused because the trial ended ends with it. See From the terminal.

A heads-up before your trial ends

In a free trial’s last seven days, a successful dibbla deploy or git push ends with a short reminder of when the trial ends and the link to upgrade; your apps keep running afterwards, only deploys pause. dibbla status says “ends in N days” with the link, and agents over MCP get the same reminder from platform_whoami and platform_deployment_start so they can tell you in the chat. See A heads-up in the trial’s last week.

2026-09-23

A friendly way forward when your trial ends

When a free trial ends, dibbla deploy, git push, dibbla db create and agents over MCP now say so plainly — thanks for trying Dibbla, your apps keep running — and link straight to the upgrade page in the console, with the Business price. The link is also in --json output and in the MCP error as upgrade_url, so an agent can hand it to you in the chat. Hitting a plan’s app or database limit links the same way. See What hitting a limit looks like.

2026-09-21

Moving away from Dibbla, written down

dibbla export <alias> takes everything an app keeps on Dibbla into one directory — the source as a git repository, databases as pg_dump archives, buckets as files, the environment as dotenv, the manifest, and a docker-compose.yml that runs it all on a laptop. Secret values stay out unless you ask for them. A new page, Moving away from Dibbla, is the procedure around it: what you get, how long you have (30 days to switch, 30 days to retrieve after that), and that it costs nothing — the Data Act information that §12 of the Terms commits to. See the dibbla export reference.

2026-09-20

The connector never takes a secret’s value

platform_secret_write no longer has a set action or a value argument. When an assistant needs an API key, a password or a token, it asks Dibbla for a secure link, writes a short title and a plain-language explanation of what the key is and why the app needs it, and hands you the link. You sign in to the Console and enter the value on a page that shows those words above the field; the assistant learns only that it was saved. A client still holding the old tool definition and sending a value is refused before anything is stored, with the request flow named in the answer. dibbla secrets set in the CLI is unchanged. See Giving the assistant a secret without pasting it.

2026-09-10

The platform connector is open to everyone with a Dibbla account

Connecting an AI agent to Dibbla no longer depends on being on a list. Until today https://mcp.dibbla.com/platform ran as a gated pilot: an account that had not been added to it was refused at the approval page, which is a fine way to roll something out and a poor way to ship it. Any signed-in Dibbla user can now connect a client, approve what it may do, and use the read tools straight away — and tick the write scopes on the same page to let it change things.

Nothing about what a grant may do has changed. Consent still starts read-only, every write is a box you tick rather than something a client is handed, destructive operations still require a separate human approval in the Console, and a grant still reaches exactly one organization. Existing connections keep working untouched; none had to be reconnected.

See Connect an AI agent.

2026-09-06

A deploy from an agent lands, instead of waiting for approval

Immediate rollout is now what every Dibbla organization starts from. Until now, organizations that existed before the rollout policy setting was introduced carried a four-eyes requirement they had never chosen — written for them, not picked by them — which meant a deploy from a connected agent or from the CLI came back as a pending deployment for a colleague to approve. Those organizations have been moved to immediate rollout and told about it.

Review has not gone anywhere: an owner or admin turns it back on under Organization settings → Deployments, for the whole organization or for a single app, and organizations that had deliberately chosen a review policy keep it untouched. What changed is only what you inherit when you have not chosen. See Deploy from an agent.

2026-09-01

Maintenance agent: proven in production, ready for gradual opt-in

The maintenance agent ran its first full verified chain in production on Dibbla’s own checks-canary control app. A run found a planted defect, opened an evidence-based proposal, notified the organization (application.maintenance.* events now have producers behind them — subscribe and they arrive by email), waited for an approval from someone other than the author, deployed, and was post-verified. The nightly schedule then took over on its own: a run started by the scheduler, with real model and tool usage, read the app’s logs, its deployed source and its check history before reporting found_nothing — and it reported that only because every mandatory evidence tool had actually run. Runs that skip evidence are refused with a typed REQUIRED_TOOL_MISSING instead of a comfortable all-clear. An emergency disable drill mid-run stopped new spend and writes immediately and fenced the run’s leases.

Every organization and every app remains off until someone opts in. The next steps for operators are a written runbook: enable the org, name the app, watch the first run, and how to disable fast.

Maintenance agent: a verified guide, CLI reference and skill

An opt-in overnight agent can now be followed from the docs: Maintenance agent hangs off Stage 5 as a detour, with a matching CLI reference for dibbla apps maintenance and dibbla apps proposals. The agent reads logs, source and check history, then either reports nothing, records a finding, or opens a change a different person approves. It never deploys on its own.

Availability is controlled per organization and per app. Both switches ship off.

2026-08-30

Connect an AI agent to Dibbla over OAuth

Dibbla now has a general platform MCP connector at https://mcp.<domain>/platform. Connect an AI agent walks through setup for Claude, Codex, Gemini and other remote MCP clients, browser consent, and an end-to-end connection check before the first tool call.

The connector can inspect apps, services, deployments, logs, databases, storage, workflows, operations and file transfers. Write access is separate from the default read consent. Routine retries are idempotent, secret values are write-only, destructive deletion requires independent human approval, and file bytes stay outside the model. The exact remotely available operations remain derived from the platform capability contract.

Availability is controlled per Dibbla installation. An operator can disable /platform without disabling the existing support, notification or community MCP toolsets. On Dibbla’s hosted service the connector is open to every Dibbla user.

2026-08-24

Pricing now leads all the way to signup and a reviewed Checkout

The Free and Standard cards on dibbla.com/pricing no longer end at a contact form. Sign up free carries a new user through login and organization creation; the new organization receives 30 days, with no card required. Existing users simply continue to their current organization and plan — clicking never resets a trial.

Sign up for Standard carries the same intent through login and onboarding, then opens an authenticated console review. The review names the organization, plan cadence and current base price. Opening it creates no Stripe Checkout Session: only Confirm and continue to Stripe does. If the active organization changed in another tab, the confirmation is refused before Stripe is called. Enterprise, externally billed, self-hosted and existing Standard organizations remain outside the purchase path.

See plans & limits.

2026-08-23

One machine, several Dibbla servers

A second dibbla login used to overwrite the first. It no longer does. A context is a named login target — an API URL, its token, and the organization you act as there — and several live side by side:

dibbla login --context prod --api-key=<token>
dibbla login --context acme --api-url https://api.example.com --api-key=<token>

dibbla context list               # both, with the one in use marked
dibbla apps list --context acme   # just this one command
dibbla context use acme           # from now on

• Nothing to do if you only use one server. Your existing login became a context called prod the first time you ran the upgraded CLI, keeping its organization pin. No re-login, and no change to how anything behaves.
• Tokens stay apart. Each context keeps its own token in the OS keyring under its own key — no host gains a plaintext credential it did not already have. The list itself is a plain, editable YAML file at ~/.config/dibbla/config.yaml holding no secrets.
• CI and scripts are untouched. With DIBBLA_API_TOKEN set — or anywhere a CI environment is detected — no config file and no keyring is read at all. Environment variables still win over every context.
• --context <name> works on every command for a single invocation, without changing what is selected. DIBBLA_CONTEXT does the same for a shell.
• Wrong names fail loudly. A --context that names nothing, or a config.yaml that will not parse, is an error — neither quietly falls back to production.

Requires CLI v1.2.61; run dibbla update. See dibbla context.

Every new organization starts on a 30-day trial

Creating a workspace — personal or for a team — now starts a 30-day free trial, and no card is collected. The end date shows in the console, on the portal welcome screen and in dibbla status.

• Creating an organization is open to anyone. It used to be limited to a short list of e-mail domains; that restriction is gone.
• Joining an existing organization does not start a new trial — you inherit that organization’s plan, so joining a paying team gives you the paying team’s plan.
• When a trial ends, your apps keep serving. Deploying and creating are paused until you upgrade; nothing that is already running is touched. See plans & limits.

Support tickets can carry a file

A reporter can attach the screenshot instead of describing it, and your team can attach one to a reply. Up to 10 MB per file — images, PDFs, plain text, CSV, JSON, .docx and .xlsx.

• Nothing to configure. Files are stored by the platform. Turn support on and the picker is there.
• A file is as private as its ticket. Whoever may read the ticket may open its files; a ticket set to own keeps its files to its reporter and your team. Uploads and downloads both go through Dibbla, so there is no shareable link to leak.
• Files leave when the ticket does — with a deletion on request, and with the 24-month retention sweep.
• Dibbla checks the size and the type, not the contents: attachments are not scanned for malware. Treat one the way you would treat a file emailed to your support address. See files on a ticket.

Managed storage: S3 buckets, operated like databases

Apps that need somewhere to put files now get one the same way they get a database — one command, and the credentials arrive on their own:

dibbla storage create my-uploads --size 25Gi

• The credential is scoped to that bucket alone. It cannot read, write or list anything else on the platform, and it lands in your app as four STORAGE_<NAME>_* environment variables. Nothing is pasted into a config file or shared between apps. See the storage guide.
• The quota is hard. A full bucket refuses uploads rather than quietly growing, and --expire-days lets data that ages out clean itself up.
• Rotation does not mean downtime. dibbla storage rotate mints a new key, updates the secrets and restarts the bound services — because pods read their environment at start, skipping the restart would leave a running app holding a dead key.
• Also in the console under Storage, and in the dibbla storage reference.

Underneath, the platform’s object storage grew up at the same time: a pinned image with health probes and resource limits, network policy so only services that hold a binding can reach it, nightly off-cluster backups — and the platform’s own Postgres now archives to object storage as well, so production databases are restorable rather than merely replicated.

2026-08-22

Your app’s users can now reach you

Every app can offer support tickets — a ticket flow the platform hosts, switched on per app, with no code in your app and no second login for your users:

• In your app: one <script src="/_platform/support.js"></script> tag puts a support affordance on your app’s own origin. Signed-in users get a compose form; everyone else gets a sign-in prompt that returns them where they were.
• In the portal: /support is one inbox for a user’s tickets across every app they use, and each app keeps its own thread page.
• In the console: a per-app Tickets tab for triage — reply, assign, set status and priority, and leave internal notes the reporter never sees. Owners and admins can switch support on right there, without editing YAML and without a redeploy.
• For agents: the same queue over MCP at mcp.dibbla.com/support.

Who may read a ticket follows who may open the app — no second access model — with a visibility: own setting for apps where that is too wide. Closed tickets are deleted after 24 months, and can be deleted on request sooner. See Support tickets, and the new dibbla.yaml reference for every field the manifest accepts.

Webhooks, Discourse, and notifications for agents

The notification layer’s last channels are live, and the whole layer is now complete:

• Webhook: paste one endpoint URL and your own systems get notified — each delivery signed (HMAC over payload + timestamp) so your receiver can verify sender, integrity and freshness against a documented recipe. Thin payloads: identifiers and a summary, never the full event body.
• Discourse: organizations with their own forum can have notifications posted as topics, attributed to the acting user — never silently as an admin.
• Agents: an agent holding your API token can read and acknowledge your notification stream over MCP at mcp.dibbla.com/notifications — the same stream you would get by email, scoped strictly to you.

Plan limits are enforced — with honest errors

The plans introduced with the billing foundation now mean something: on plan-billed organizations, the Free trial includes 3 apps and 2 databases, Standard includes 15 and 10 (individually adjustable per organization). Hitting a limit refuses the action before any upload or build, with an error that names the numbers and the remedy — and the CLI now prints a Docs: link to the new Plans & limits reference on these errors. Three guarantees worth knowing: an organization exactly at its app limit can always redeploy the apps it has, running apps and databases are never touched by any limit, and organizations without a plan — including every self-hosted installation — have no limits at all. The console’s Plan tab now shows usage bars, dibbla org list gained a PLAN column, and dibbla status shows your plan and trial days.

Notifications now happen by themselves

The notification layer’s channels have had nothing to say until now — that changes today. Support tickets and failed deployments notify automatically:

• Reply to a ticket and the reporter gets an email — scoped to their own tickets, never for their own replies, with the usual one-click unsubscribe.
• Connect a Slack webhook and new tickets announce themselves in that channel from that moment — configuring the channel is the setup.
• A failed deployment produces a deploy.failed event you can subscribe to — including background rollouts where nobody is watching a terminal, which used to fail silently.

Notifications never slow down or break the thing they report on: events are written alongside the change itself and shipped afterwards, so filing a ticket or deploying works exactly the same even if the notification system is down. See the new Notifications guide.

2026-08-21

Slack notifications

Notifications can now go to Slack. In your organization settings, add a Slack incoming webhook under Integrations and subscribe the events you care about — the matching notifications post to that channel. Each message is a short summary with a link into Dibbla, never the full contents, since a channel is a wider audience than a ticket thread. If the webhook is later removed in Slack, Dibbla notices on the next send and disables the connection rather than retrying a dead URL. Your webhook is stored encrypted and never shown back to you.

Email notifications

Dibbla can now send email notifications. The platform gained a notification layer earlier — a durable event log with per-organization subscriptions — and it now has its first delivery channel: email, sent from notify.dibbla.com with SPF and DKIM aligned so messages land in the inbox rather than spam.

Every notification email carries a one-click unsubscribe link (and the standard List-Unsubscribe headers, so your mail client can offer its own button). Unsubscribing is immediate and needs no login — the link disables exactly the one subscription that sent the mail, nothing else.

Nothing sends until an organization configures it, and self-hosted installations send nothing until an operator sets up SMTP — see self-hosting with Helm.

Organizations can now hold a plan

The platform has grown its billing foundation: an organization can be on a Free trial, Standard, or Enterprise plan, matching the tiers on dibbla.com/pricing. Self-serve upgrades run through Stripe Checkout, and card and subscription management through the Stripe customer portal — Dibbla never sees your card details. The console’s organization settings gain a Plan tab with the upgrade and billing actions.

This is rolling out gradually: the Plan tab and upgrade flow appear once billing is switched on for your installation, and self-hosted installations carry no billing surface at all. Nothing changes for existing organizations — no plan is assigned retroactively, and no limits are enforced yet.

2026-08-12

Skills are fetchable over HTTP

The Dibbla agent skills are now published at https://dibbla.com/.well-known/agent-skills/index.json, following the Agent Skills Discovery RFC (Draft 0.2.0). An agent with no dibbla binary can fetch the skill directly; every entry carries a sha256: digest to verify against.

This is a second supported install path, not a replacement. dibbla skills install still needs no network and still gives you the skill version matching your CLI. The mirror is pinned to a tagged release, so it is version-locked too — see Fetching the skill without the CLI.

CLI v1.2.47 – v1.2.49

• dibbla deploy and dibbla apps update gained --env-file, and there is a new dibbla secrets import for bulk-loading a .env into secrets.
• Skill content corrections: examples now point at production hosts rather than staging, and the “no network required” note is scoped to the CLI install path now that the same files are served over HTTP.

dibbla.com

• A published FAQ — 17 questions, deep-linkable, readable without JavaScript.
• Per-page titles and canonical URLs, a real 404, and dibbla.com/docs now redirects here instead of silently serving the home page.
• llms.txt gained an FAQ index, and there is a new llms-full.txt carrying the whole site’s content in one fetch.