bootload
⚓ portal

Changelog

2026-10-22 — PHP's critical security fixes: Bootload is not affected, your PHP services may be

On 21 October PHP released 8.2.35, 8.3.36, 8.4.27 and 8.5.12. They fix two critical bugs, CVE-2026-109618 and CVE-2026-109619. Both let a crafted multipart POST run code on the server, before any login, against any PHP endpoint. Every older PHP is affected, whatever application runs on top of it.

Bootload itself runs no PHP. The control plane, the edge and the nodes that run your services were never exposed, and nothing on our side needed a patch.

Your own services are a different question. The day after the release we read the PHP version straight from the disk of every running service, rather than trusting image tags: a tag can keep saying 8.3 long after the base image moved on. A few services shipped an affected version, and we are contacting each owner through a support ticket. If no ticket reaches you, none of your running services had an affected PHP when we checked on 22 October.

If you run PHP on Bootload, this is the fix:

2026-10-18 — restricted API keys stay restricted, and a batch of account hardening

A project-restricted API key could reach your account settings. Keys can be narrowed to certain projects and scopes so a CI pipeline or an agent holds only the power it needs, but the account endpoints under /v1/profile/* never checked that restriction. A read-only key for one project could regenerate the account's 2FA backup codes, export all account data, list and revoke every other key and session, and change the password if it also knew the current one. Every credential and account endpoint now refuses restricted keys with 403; only a full-access login session can use them. Restricted keys keep working for everything they are scoped to, and the project list now only shows the projects a restricted key may see. If a script of yours called /v1/profile/* with a restricted key, it now needs a full-access key. Full write-up in advisory BL-2026-009. Thank you, Shambhi Reddy Chemikala.

Email verification is now enforced. An account that has not confirmed its email address can sign in and finish setting up, but cannot deploy, scale or restart anything, and receives the welcome credit only once the address is confirmed. Existing accounts are not affected.

Smaller fixes from the same round of reports:

Thank you to every researcher who reported these. The ones that qualified are credited in the security advisories.

2026-10-02 — six AI models retired upstream, two embedding models and an extraction model added

Our model provider retired six models on 29 and 30 September: qwen3.6-27b, qwen3-5-122b-a10b, qwen3-omni-30b-a3b-thinking, nemotron-3-nano-omni, medgemma-27b and hy-mt2-30b-a3b. They are gone from /v1/inference/models and from the AI models page; a call to one of them now answers 404 MODEL_NOT_AVAILABLE from us instead of a 503 from upstream. If you were on a Qwen model, gemma-4-31b is the closest match we serve today, and glm-5.2 the stronger one. We are asking for qwen3.8-27b to be opened on our keys and will list it the day it is.

Two things were wrong on our side and are fixed. The catalog only ever added models, so the retired ones stayed listed for three days; the sync now retires what the upstream stops serving, in the same pass. And the provider's model list contains models our keys may not call, so the sync now checks each model with a one-token call before listing it — nothing goes on the page that would 403 in your hands.

New in the catalog: qwen3-embedding-8b (4096 dimensions) and bge-m3 (1024) at POST /inference/v1/embeddings, billed on input tokens only, and nuextract-3 for structured extraction. These three have no OpenRouter listing, so the pricing rule gets a second clause: a model with an OpenRouter reference is priced at that reference plus 20%, as before; one without is priced at the provider's list price plus the same 20%. The per-model table is still the contract.

One correction. Since the retirement, a request for glm-5.2 is answered upstream by glm-5.3-flash. We now price it as what it is, which cuts it from €0.44 to about €0.16 per million input tokens and from €4.24 to about €0.54 per million output tokens, and the catalog says "served as glm-5.3-flash" next to it. The speech models (whisper-large-v3, -turbo) bill per minute, which our meter cannot do yet, so they are not listed.

2026-09-19 — deploy hooks, an organization view, and apps that know their own domains

A customer sent us thirteen precise notes. Six were bugs, and two of them turned out to be one bug. This release closes the bugs; the rest is on the roadmap.

CI can deploy without an API key. A deploy hook is a signed URL your pipeline posts to after pushing an image: bootload deploy-hook create web prints the URL and a secret, once. Posting {"tag":"v2"} rolls the service onto that tag, and an empty body re-pulls the configured image, which is what a mutable tag wants. What matters is the thing a hook cannot do. It reaches exactly one service and cannot leave the repository that service already runs, so a hook leaked in a CI log lets someone roll a different tag of your own image instead of deploying arbitrary code. Sign with X-Bootload-Signature: t=<unix>,v1=<hmac>, the same scheme as wake webhooks, or pass ?token= when your CI cannot sign. Manage them from the CLI (bootload deploy-hook), the portal's service settings, or MCP. Two GitHub Actions come with it, setup-bootload and deploy, published at bootloadio/cicd along with copy-paste pipelines for GitHub and GitLab. The deploy action signs each call instead of putting the secret in the URL. The CI docs show both the hook and API-key shapes.

There is an organization view now. "I don't see where I can go to an org view," one of you wrote. Organization in the portal sidebar shows the org's slug and registry namespace, every project with its balance, spend this month, cap and runway, the fleet total, and the member list. Because each project still has its own wallet, the page says plainly that the fleet's runway is set by the project that runs dry first, not by the total.

Domains are in the portal too. Attaching and detaching a domain on a running service used to be CLI-only. The service settings tab now lists every domain, attaches another, and shows the DNS record to create when we do not manage the zone.

Your app knows its own domains. A container now starts knowing what it is and where it answers. Every container gets BOOTLOAD_SERVICE, BOOTLOAD_PROJECT, BOOTLOAD_IMAGE, BOOTLOAD_DEPLOYMENT and BOOTLOAD_REPLICA. Anything with an HTTP route also gets BOOTLOAD_FQDN, BOOTLOAD_URL, BOOTLOAD_PORT and BOOTLOAD_FQDNS, which lists every domain the service answers on, separated by commas. That answers "can I link several domains to one app, and can I get dynamic variables from them?" with yes to both. Attach as many domains as you like, read BOOTLOAD_FQDNS at startup for allowed hosts, CORS origins or a canonical URL, and keep reading the Host header to decide what to serve per request. Your secrets still win: image environment first, then platform variables, then your secrets. A routeless service gets the identity variables and none of the URL ones. They are absent rather than empty, so a missing value fails loudly instead of building a link to https://. Attaching a domain does not restart your app, so new values appear on the next restart. bootload status and the service page both list them. Reference: environment variables.

Health looked at the wrong replica. A service's health verdict and its "why isn't this healthy" diagnosis considered every replica the service had ever had, oldest first. Two things followed. A rollout that recovered kept a failed count forever, and the diagnosis explained today's outage with the first failure ever recorded. Worse, a service asleep in Idle Harbor, suspended on purpose and waking on the next request, counted as zero healthy replicas and showed as in distress. Now terminal replicas of earlier deployments are history and stay out of the verdict, the counts and the diagnosis. The diagnosis quotes the newest failure and names the replica, and a suspended service is reported as asleep, which the portal calls "in harbor". Never down. The services list carries the same one-word verdict (health) so the overview, the CLI and agents stop deriving their own.

Download log produced a 34-byte file. The portal asked for more lines than the interactive cap, and it spelled the download flag differently from what the API checked, so the error JSON was saved as the log. Fixed on both sides, and an error now shows as a toast instead of a file.

token create --project takes a name. Every other --project flag accepted a project name or id; this one wanted the id. It resolves names and slugs now, across your organizations, and refuses an ambiguous one.

Images, by project. Your pushed images stay org-wide, so you push once and deploy from any project, but the hub images card now opens on what the current project can deploy: its own namespace plus the shared one. It labels each image with where it lives, and says which service is using an image instead of showing a disabled delete button. bootload image list prints the same labels. bootload image push --shared publishes into the org-wide namespace explicitly, and without a selected project the CLI now asks you to pick --project or --shared rather than guessing. The API takes GET /v1/images/mine?project_id=.

Response schemas for agents. Twelve of the most-read endpoints now publish the shape of their 200 response in the OpenAPI spec: services (list, detail, health, deployments, logs), pushed images, projects, organizations, wallet, volumes, backups and domains. The schemas are generated from the server's own response types, and a test fails when they drift, so they will stay true.

In the docs: several domains on one service (bootload domain attach) and how to tell them apart with the Host header, image push --shared, and project use in getting started.

2026-09-18 — CLI v0.1.21: project use, a non-production warning, and a note on x86-64

bootload project list marked your current project with a *, and creating a project made it the default, but there was no command to move that default. You either created another project or typed --project on every command. Now: bootload project use <name>, and bootload org use <slug> for organizations. The list also says so at the bottom.

The CLI now warns, on every command, when it is talking to a host that is not production. A few early testers installed it in June against our test fleet and were still pointed there months later, with the browser on production and the CLI on test, and nothing said so. It does now.

One thing worth stating plainly in the docs, which we had not: bootload runs x86-64 (linux/amd64) images only, for now. An image built only for arm64 will not deploy. If you build on Apple Silicon, add --platform linux/amd64; multi-architecture images that include amd64 work as they are.

Update with bootload self-update, or reinstall from the docs.

2026-09-16 — wake an idle service on a schedule, or by webhook

Idle Harbor suspends a service that has gone quiet and wakes it on the next request. Until today that request was the only thing that could wake it, so the first visitor after a quiet spell always waited for the boot, and a service with no public route could not be woken at all.

You can now wake a service ahead of time. Give it a cron schedule, weekdays at 08:00 in your timezone, say, and it is awake before anyone arrives. Or create a webhook URL and let something else wake it: a CI run that is about to send traffic, a queue that just filled, a scheduler you already run. There is a "wake now" button too. Waking only resumes what was suspended. It never scales or redeploys, and a service you parked at zero stays parked.

bootload wake, the scheduled-wake panel on the service page, and the services_wake / wake_triggers_* MCP tools. Webhook secrets are shown once, signed calls are replay-protected, and each URL is rate-limited. A scheduled service is awake, and billed, from each fire until it idles again.

2026-09-09 — every project gets its own registry namespace

Images you push now land at registry.bootload.io/<org>/<project>/<image> instead of one namespace per organization. bootload image push picks the project you have selected (or --project), and a deploy without --image looks there first.

The reason is CI keys. A key limited to one project could authenticate to the registry and then push over any image in the organization, because the registry only ever checked membership. It now checks the project too: a limited key reaches its own projects' namespaces and nothing else. The same rule applies to listing, deleting and pruning images. And bootload image login no longer fails with "the new key must name a subset" when run with such a key; it mints a registry key limited to the same project.

Images pushed before today keep their org-wide address and keep deploying.

2026-09-05 — bootyard: invite reviewers, collect what they find, build from it

A bootyard app can now be handed to people who have no account with us. Invite a reviewer by email and they get a link. When they ask to sign in, a pincode arrives in their inbox, and that code is the whole credential: no password, no account, and no access to anything except the app you invited them to.

They open your published app, take screenshots, and annotate them where something is wrong. That comes back to you as feedback you can read and reply to, and any piece of it can be turned into a build prompt. Prompts collect per issue, so you choose which ones to run rather than taking them one at a time. When the new version is up, everyone who reported something against it is told. Turn a piece of feedback down and the reviewer hears that too, with a fresh pincode if they want to look again.

2026-09-05 — your sessions end when you say they end

Two faults here, and both are worth stating plainly rather than burying.

Changing your password, or completing a password reset, was meant to sign out every other session. In production it signed out none of them. The query that clears the others compared against an empty value where the database expected an identifier, so it matched nothing, every time, and reported success. If you have ever changed your password because you were worried someone else had access, change it once more. This time it does what it always said it did.

Separately, "log out my other sessions" only removed sessions created by an ordinary password login. Sessions created by a two-factor sign-in, by verifying an email address, or by changing a password were left running. The people most likely to reach for that button, anyone with two-factor turned on, were the ones it served worst. It now recognises a session by what a session actually is, rather than by a list of names that had fallen out of date.

2026-09-05 — a wave of security reports, answered

Independent researchers filed fourteen reports over the past fortnight. Ten were valid and are paid; the fixes shipped as one batch.

The one that mattered most: our production login rate limit had been running our development values, roughly ninety attempts a minute per address instead of thirty. The code was correct the whole time and only the deployed configuration was wrong, which is the kind of fault that no amount of reading the source will reveal and only somebody probing from outside will find. It is now pinned where nothing can override it.

With it: API key creation, volume creation and affiliate link verification are rate-limited, and an account has a ceiling on how many keys it can hold. Three further limits existed in our code but had never run once in any deployment, because the line that switches them on was missing. The portal and admin console now send framing and content-type protection. Organisation names must contain at least one visible character, after a report showed a name built entirely from zero-width characters rendering blank in member lists and in the deletion dialog. Signup and invitations check that an address can receive mail at all. We also moved onto patched Next.js, Go and x/crypto releases.

Credits and severities are on the security page.

2026-09-05 — DNS records you can read, sort and trust

The domain records screen was an undifferentiated wall of rows. It is a proper table now: sortable, with type and name in their own columns, values that no longer wrap into soup, and a delete that asks before it acts.

Underneath it were two real faults. Records came back from our registrar with the zone name repeated on every row and TXT values still wrapped in the quotes the registrar stores them with, neither of which belongs on screen. And deleting a TXT record silently did nothing: the request went in a form the registrar accepted and then ignored, so the record stayed and the screen said it had gone. Both fixed and checked against a live zone.

2026-09-05 — two portal repairs

The Members page told anyone who was not an owner or admin that the organisation had no members. It has them. The page fetched the member list and the pending-invitation list together, and since only owners and admins may read pending invitations, one refusal discarded both results. Developer, billing and viewer members, three of the five roles, saw an empty page. Fixed, and the management controls now appear only for people who can use them.

And when creating a project-scoped API key, the project picker was always empty, so a key could not be narrowed to a project from the portal at all. It loads.

2026-08-25 — four new security advisories published

Independent researchers spent the week on our organization and invitation flows, and we shipped the fixes as one batch: an invitation is now bound to the address it was issued to (it could previously be redeemed by anyone holding the link), accepting an invitation can no longer overwrite an existing member's role, and the "an organization always keeps one owner" rule is now enforced inside a single locked transaction so it can't be raced away by simultaneous requests. Email-verification links now retire the older ones, and build creation is rate-limited. We also moved the control-plane edge onto a patched NGINX after a version-disclosure report prompted us to check. We were not exploitable, and no customer application was served by the affected component. Full write-ups, CVSS scores and researcher credits are in the security advisories (BL-2026-004 through BL-2026-007).

2026-08-25 — hosted S3 object storage, public if you want it

New on the databases shelf: an S3-compatible object store. 100 GB on an encrypted volume, provisioned in one command (bootload database install s3) with generated keys, private to your project by default. Every S3 SDK, the AWS CLI and presigned URLs work. Two more commands take it as far as you like. bootload exposure s3 public gives it an https address under the platform domain, and bootload domain attach assets.example.com s3 puts your own name in front of it, with the certificate issued automatically. That last command is new for every service, not just the S3 store: you can now attach or detach a verified domain on anything that's already running. The full walkthrough is in docs → S3 object storage.

2026-08-25 — uploads over 1 MB now work everywhere

While testing S3 uploads we found an embarrassing one. An internal proxy hop still had its default 1 MB body limit, so any upload above 1 MB through a service's public URL was rejected, regardless of what your app allowed. Fixed fleet-wide: the limit is now 50 MB per request end to end, and bigger objects go via multipart, which S3 SDKs do automatically. If your users ever saw a mysterious "413" on an upload form, this was it, and it's gone.

2026-08-25 — backups you can actually operate

Three long-standing gaps in one batch. Restores of big services no longer time out: a whole-service restore now runs in the background, you get an answer immediately, the portal and CLI follow its progress, and the new ship appears when its data is aboard. Service backups can be deleted, with a portal button and bootload backup delete-service <id>, and stuck ones are cleaned up automatically instead of wedging forever. And bootload update --dry-run shows what a deploy would change, including the image, the resources, the €/month delta, and whether it means downtime, before you commit to it.

2026-08-25 — when a ship won't sail, the portal now tells you why

A failing service used to show a state and leave the diagnosis to you. The service page now explains it in plain language, with the matching fix suggested next to it: out of memory, image can't be pulled, health check timing out, no capacity, crash on boot. New accounts also get a small first-voyage checklist on the home page (verify, account details, project, launch) that disappears once you're sailing. Skip it any time.

2026-08-25 — bootyard: versions you can hold on to

A round of bootyard upgrades from the workshop floor. Every build round now shows its timeline, which is what the builder did phase by phase, and what changed from the previous version. Any past version can be made live again with one click ("make this version live"), and old build images beyond your stack's keep window are cleaned from the registry automatically, while published and running versions are always kept.

Starting fresh got friendlier too. An empty yard offers proven starting points (landing page, storefront, internal tool, REST API…) that seed a first prompt known to build. A 🎨 match a design button reads the colour palette from a screenshot or logo right in your browser and hands it to the builder. Credentials can be tested against their provider before you save them, and a 📱 button hands you the app's address for your phone.

2026-08-23 — account security, hardened

A group of independent researchers spent the week probing the account and organization screens, and we shipped their findings as one batch. Turning on two-factor authentication now asks for your password and signs out your other sessions. Deleting an account asks for your password and your 2FA code. The invite, organization, ticket, and password-reset flows are rate-limited so they can't be used to flood inboxes. Names can no longer smuggle in a link, verification links expire the moment one is used, and after you log out the browser Back button no longer shows your account pages. None of this touched your running services, and we found no sign of misuse. Full write-up and researcher credits are in the security advisories (BL-2026-003).

2026-08-23 — platform disaster-recovery backups, offsite

Behind the scenes we now take encrypted, offsite backups of the platform's control plane, verified end to end: the database that holds your account, projects and service configuration, plus the container registry and platform config, all copied to a hardened server in a separate location. This is our own disaster-recovery safety net. It doesn't replace your own service backups, which still live under backups. It means the platform itself can be brought back if the worst happens.

2026-08-22 — AI model prices cut by up to 80%

New pricing rule for the inference gateway: every model is now priced at the OpenRouter reference plus 20%, which is simple, public, and checkable. In practice that is a big cut. deepseek-v4-flash went from 41 to 8 cents per million input tokens, gemma-4-12b from 25 to 6, glm-5.2 from 481 to 100. The per-model table at /v1/inference/models, and on the portal's AI models page, is the contract. What it says is what your wallet pays, billed per token as always.

2026-08-22 — a portal you can actually navigate

The menu grew with the platform until "where do I find X?" became a fair question. It is now organised by task rather than by history: build (services, databases, apps, yard), data and config (secrets, volumes, backups, images), traffic (domains, public IPs, mail, webhooks), billing, and support. The old kitchen-sink resources page is gone. Secrets, volumes, backups, images and public IPs each have their own page now, and old links redirect. Account credentials split out too: password and two-factor live under security, tokens under API keys.

Two quality-of-life pieces shipped with it. The secrets page has a paste-a-.env box that stows a whole file of KEY=VALUE lines in one go, handling comments and quotes, reporting invalid lines, and respecting service-scoping. And a bug that could take the whole resources page down for accounts with volume-less service backups is fixed.

2026-08-22 — you asked, we shipped (the ideas board works now)

A batch of feature requests landed on the ideas board this week, including, fittingly, "voting doesn't work" and "clicking ideas switches me to dark theme". Both confirmed, both fixed: voting is live on every published idea and stays open until an idea ships, and the theme no longer flips on that page. The board itself is now actively tended, and every request in this batch was reviewed, published, and answered with a fix where one was due. Post an idea from the portal's ideas page; the crew reads them.

2026-08-20 — the ship's manual, one click from every page

The portal has a docs screen now: the full manual grouped by task, CLI and API references, and a section for AI agents with the machine-readable docs (llms.txt), installable skills, MCP setup for every client, and ready-to-paste starter prompts for deploying, wiring CI/CD, or investigating a service with your coding agent of choice.

2026-08-17 — account-security hardening

We confirmed and fixed a batch of account-security reports from an independent researcher, all the same day. Password changes now invalidate every outstanding reset link and rotate your session, so every old credential stops working and a fresh one is issued. Passwords are screened against a common-password and trivial-pattern list, so 12345678 and friends are out. And signup is now email-first: it never reveals whether an address is already registered, you get the same "check your inbox" either way, and the confirmation link finishes signing you in. Full write-up in the security advisories (BL-2026-002).

2026-08-17 — bootyard agent mode: the pipeline factory

Choosing agent in bootyard no longer shows a page. It shows your agent as a factory floor. Every workflow is a production line: a trigger (a schedule, a webhook, or a manual run) feeds steps along belts into outputs, drawn in a clean 3D view you can zoom, pan and click.

Behind it is a real runtime, with bounded loops, per-step timeouts and retries, batching, a dead-letter queue with replay, pause/resume, and checkpoints so a redeploy resumes instead of re-running. Webhooks are verified, by HMAC or a shared token, schedules fire on the clock with at most one catch-up after downtime, and everything runs in one always-on container on your wallet. Test runs stay on the preview and are stubbed: they show what would have been sent. The factory is owner-only, and the container is dark to everyone else.

2026-08-17 — services that wire themselves

For website, app, API and agent builds, the platform services your app uses now appear automatically: a database, transactional email, the OpenAI-compatible inference endpoint, each with its own unique key, scoped to that app and never shared with another. There is no button. The stack provisions what it implies, and anything your generated code references is attached and wired for you. A grey "needs fuel" machine on an agent's factory floor walks you straight to setting any external credential it still needs.

2026-08-16 — bootyard is live: prompt to app

bootyard.io is open, a friendly front on the full bootload machine for people who would rather describe an app than build one. Type what you want ("a booking site for my hair salon"), pick nothing more technical than website / app / api / agent, and watch a coding agent build it in a private microVM, test it, and show you a live preview. Iterate by chatting, run a security scan when curious, brainstorm and buy a domain in the same flow, and publish when you are happy, to a free subdomain or your own name. Everything underneath is the platform you already know: accounts, wallets, secrets, registry, deploys, backups, domains.

2026-08-15 — MCP without installing anything (hosted endpoint)

The MCP server now also lives in the cloud. Web-based AI clients, and anywhere you can't run a local process, speak Model Context Protocol straight to the API over streamable HTTP:

https://my.bootload.io/v1/mcp

Authenticate each request with your own API key (Authorization: Bearer), and everything you know from the local server applies unchanged: all 48 tools, scopes, the production guard, the audit trail, and the double gate on money, which here is the X-Bootload-Allow-Spend: 1 header on your session plus confirm: true per call. Nothing is stored between requests. Setup for every client stays at bootload.io/docs/mcp.

2026-08-15 — the full platform, one agent away (CLI v0.1.14)

The MCP server grew from 24 to 48 tools, full parity with the CLI for everything an agent should touch. New since v0.1.13: in-place update, restart, scale and destroy (with the destructive annotation and the production guard's emailed confirmation), exposure and Idle Harbor toggles, volumes and the whole backup suite (list, restore, delete), domains end to end (bring-your-own with verification records, DNS on our nameservers, renewal), moving wallet credit between your projects, budget caps, the rate card, managed-SMTP credentials, registry info, and secrets (names only, since values stay write-only, for agents too).

The safety model is unchanged and now covers everything: read tools are annotated read-only, money needs your standing BOOTLOAD_MCP_ALLOW_SPEND=1 opt-in plus a per-call confirm: true, and deleters carry their own guard. One line to get aboard: claude mcp add bootload -- bootload mcp. bootload self-update fetches v0.1.14.

2026-08-15 — your AI copilot gets native tools: MCP (CLI v0.1.13)

bootload now speaks MCP out of the box. claude mcp add bootload -- bootload mcp and Claude Code, Claude Desktop, Cursor or Codex get the platform as typed tools: projects, deploy, status, deployment history, logs, metrics, wallet, domains, backups, tickets and the app catalog, plus services_wait, which only reports success once your service is really healthy, running or routable.

The safety model: read tools are marked read-only, and money-spending tools are double-gated. The server refuses them unless you start it with BOOTLOAD_MCP_ALLOW_SPEND=1, and each call still needs an explicit confirm: true. Your agent can look around all it wants; it spends nothing without your standing policy AND a per-call confirmation. Setup for every client at bootload.io/docs/mcp.

Also in this release: scale-to-zero truly works now. Idle Harbor wakes a sleeping service from its snapshot in well under a second on the first request; the wake path had crashed since launch and is fixed root-and-branch. Platform mails render correctly on Gmail mobile, only billing mails mention topping up, and the welcome mail now points AI copilots at llms.txt. bootload self-update fetches v0.1.13.

2026-08-14 — move credit between your projects (CLI v0.1.12)

Your credit now sails wherever you need it. You can move wallet credit between two projects of the same organization yourself, with no support ticket and no workaround. On the portal wallet page it's a one-line form (amount and destination project); in the terminal it's

bootload wallet transfer --to staging --amount 25

and for scripts and agents there's POST /v1/wallets/{id}/transfer (with --json on the CLI). Every move is atomic, so both ledgers update together or not at all, the source can never overdraw (you get a clean WALLET_EXHAUSTED error instead), and it requires a money-moving role: owner, admin, or billing. Moving credit across organizations remains a job for our crew, fully audited.

Also in this release: buying a domain you had first added as bring-your-own now upgrades it in place. That combination could previously leave a freshly registered domain stuck "pending verification" and never charged; the flow now settles ownership before any money moves at the registrar. bootload self-update fetches v0.1.12.

2026-08-09 — built for agents, and mail that really sends (CLI v0.1.11)

Driving bootload from an AI agent or a CI pipeline is now a first-class path. Every command takes --json for one clean, parseable document instead of scraped text. --wait and --wait-until healthy|routable block until what you asked for is actually true, and success prints only once it holds, so your next step can trust it. --request-id makes a retried deploy or create idempotent, so a dropped connection can't double-apply. New bootload update <service> changes a running service's image or resources in place, with no re-deploy conflict, and bootload capabilities, along with GET /v1/capabilities, hands an agent the whole feature map: what's stable, what scopes it needs, what costs money, what's reversible. Errors now carry stable codes (BACKUP_NOT_FOUND, WALLET_EXHAUSTED, …) to branch on, and our llms.txt documents the complete command surface. bootload self-update fetches v0.1.11.

We also went back over a stack of rough edges and made them honest. Backups verify, export and delete reliably, and bootload backup delete lands in the CLI, stopping a backup's billing the moment it's gone. bootload exec now returns your command's real exit code, so CI and agents stop reading a successful command as a failure. Rollouts are zero-downtime, with the old version serving until the new one is healthy. Billing shows exact sub-cent cost, burn rate and runway instead of a rounded €0.00, so short runs and cleanup decisions have real numbers. Empty metrics say "still collecting, check back" rather than looking broken. And Idle Harbor genuinely sleeps an idle service to disk now and wakes it on the next request.

Managed SMTP now delivers. Point your app's mailer at host smtp.bootload.io, port 1587, STARTTLS, using the credentials from your project's Mail page. (Why 1587 and not 587? Every app runs in its own microVM, and microVMs are blocked from speaking SMTP straight to the internet, our anti-abuse moat that keeps the fleet off spam blocklists, so 1587 is the dedicated dock into the relay.) Mail is DKIM-signed and billed at €0.001 per accepted message, as always.

2026-08-04 — security disclosure programme + a same-day fix

We published a security policy with a dedicated reporting address, security@ahoy.bootload.io, a safe-harbour for good-faith researchers, and a place where we'll list advisories.

Independent researcher N0b0t responsibly reported a cross-tenant SSRF in the deploy-time image pull: a container image reference pointing at an internal address could make a worker connect there. Exposure was limited to a connectivity probe, no customer data was exposed, and every other isolation boundary held. We shipped the fix the same day. Image pulls now refuse internal addresses and the API rejects internal registry hosts, while every public registry keeps working untouched. Details in advisory BL-2026-001. Thank you, N0b0t.

2026-08-04 — top up from the terminal (CLI v0.1.10)

bootload wallet topup --amount 50 now hands you a secure Stripe payment link right in the terminal. Open it, pay, and your balance updates the moment the payment completes. Admins also gained an audited way to move credit between a customer's projects without touching cards at all. Already sailing? bootload self-update fetches v0.1.10.

2026-07-08 — a clearer portal, a smarter deploy form

The portal got a big usability pass. A new Services page lists your whole fleet at a glance, with auto-archive so old experiments stop cluttering the view, and the service page grew a proper action bar with docked states, plus plain-language failure reasons on replicas, so "why isn't it up?" is answered on the page instead of in the logs.

The deploy form now auto-fills the port for well-known images, offers a dedicated-IP picker, and deploys are public by default, so you no longer get a silently unreachable service when you skip the domain field. Your wallet page groups the ledger by day and writes notifications in human sentences. Domains show expiry and renewal at a glance, with grouped DNS records and an on-demand check. Also: cleaner app-library cards, transparent pricing shown where you make choices, tidy toast notifications, and yes, a proper pixel-boat favicon in your browser tab at last.

For the robots among us, our llms.txt now ships an agent skill for deploying on bootload, so your AI copilot can read exactly how to sail.

2026-07-06 — maintenance that doesn't touch your apps

Platform updates on our workers used to restart the microVMs they hosted. No more: the fleet now re-attaches to running instances during agent updates, so your services sail straight through our maintenance, verified across the whole production fleet. Shutdowns also drain gracefully, with stop signals reaching every guest in parallel and a real grace period.

2026-07-05 — your mail, your DNS, one test button

Managed SMTP grew up. The submission port now speaks STARTTLS on :587 directly, so you can point any client or library at it with no proxy tricks. The portal shows your SPF, DKIM and DMARC records structured field by field with copy buttons, and a test-send button that mails a probe and shows the result in your mail history. And when your domain's zone is hosted with us, the mail DNS records are published automatically, with nothing to paste at all.

Under the hood, the private network between your services got markedly sturdier. Cross-machine connections between siblings (app → db.internal) are now watched, self-healing, and no longer depend on which machine your replicas landed on. Multi-service apps just work, wherever the scheduler places them.

2026-07-04 — backups without limits

The backup engine was rebuilt end to end. Backups now run as asynchronous jobs, so big volumes no longer time out, with sub-second freezes for a consistent snapshot, resumable streaming uploads, and room for 100 GB+ volumes. You get retention with automatic cleanup, a per-project quota, backup deletion that immediately stops its billing, and download links for taking an encrypted export off-platform.

Also in this batch: volume resizes now verify and heal the filesystem so the extra space is really there; bootload self-update keeps the CLI fresh, with downloads now served from production; and API keys can be scoped to a project and specific resources, so a CI token can deploy one app and nothing else.

2026-07-02 — your domain, end to end

Buy a domain and put it on your boat without leaving the harbor. The domains page shows live registration prices per TLD (excl. VAT), and once a registered domain is linked to a service, the DNS records are written for you, apex or subdomain, and the edge issues its TLS certificate automatically. Plain HTTP redirects to HTTPS everywhere, and the certificate plumbing stays reachable. You'll get two emails in your language: one when the domain is registered, and one the moment it's serving end to end, with DNS set, certificate hoisted, and HTTPS answering.

Reliability got the same attention. Internal services now declare the port siblings reach them on (bootload exposure <svc> internal --port 5432, and the CLI guides you), and the gateway tier was hardened so one tenant's dead route or redeploy churn can never ripple into anyone else's traffic.

2026-06-28 — bootload is live: production in France 🇫🇷

Production is open at my.bootload.io, running on our own hardware in France · Zone 1 (fr1): real Firecracker microVMs, encrypted volumes, TLS at the edge, per-second billing with real card payments. New projects pick their zone at creation, the CLI points at production out of the box, and trust.bootload.io now reports live production status.

Launch-day sweetener: hosted registry storage dropped from €0.20 to €0.03 per GB-month.

2026-06-22 — hosted databases: Postgres, Valkey & MariaDB

Give your apps a managed database in one click. Postgres, Valkey (Redis-compatible), and MariaDB join the library under a new Databases section in the portal, or run bootload database install postgres from the terminal.

They're private to your project: no public URL, nothing exposed to the internet. Your services reach them by name at <name>.internal, and now from anywhere in your fleet rather than just the same machine, so a database and the app that depends on it no longer have to land on the same node. Installing one hands you the connection string to drop straight into your app, and the data sits on the same encrypted, backed-up storage as the rest of your services.

2026-06-16 — log into your instances + new CLI controls (CLI v0.5.0)

You can now open a shell inside your running instance. bootload shell <service> drops you into an interactive prompt, and bootload exec <service> -- <command> runs a one-off command. It's a secure, proxied session over bootload's own channel: no SSH to set up, no key to manage, and nothing exposed on your container to the public internet. Production services ask for --confirm first, and every session is audited.

This release also brings a batch of CLI controls that mirror the portal:

Your hosted-hub image list (bootload image list and the resources page) now shows each image's size and push date. On mobile, the portal menu is a clean top bar again instead of crowding the screen.

2026-06-15 — push and manage your own images

Bring your own container images to the hosted registry from the CLI: bootload image login logs Docker in with a scoped token, bootload image push <local-image> puts it in your org's namespace, and bootload image list shows what you've pushed. You can now also delete images you no longer need, with bootload image delete <name:tag> or the new hub images card under resources, which stops their storage billing. Deletes are refused while a service still deploys the image, so you can't pull the rug out from under a running app.

2026-06-12 — private test fleet live

The whole platform now runs end to end on our test fleet: customer portal with signup and deploys, the one-click app library (n8n first), multi-node scheduling with least-loaded placement, encrypted volumes and verifiable backups, managed SMTP with DKIM, real TLS at the edge, support tickets, and per-second billing with runway warnings. Public launch preparations underway.

2026-06-11 — vertical slice complete

First real path through the platform: signup → wallet → deploy an OCI image → a genuine Firecracker microVM boots in ~3.4 seconds → HTTPS route → logs → metered billing. From there the build sprint added secrets, volumes, backups, TLS, domains, the image hub, metrics and logs, MCP, and the dashboard, all gated by integration and e2e tests on real microVMs.