bootload
⚓ portal

Changelog

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 (certificate issued automatically). That last command is new for every service, not just S3 — 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 (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 (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 — image, 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 — out of memory, image can't be pulled, health check timing out, no capacity, crash on boot — with the matching fix suggested next to it. 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 (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"); old build images beyond your stack's keep window are cleaned from the registry automatically (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; and 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 — the database that holds your account, projects and service configuration, plus the container registry and platform config — to a hardened server in a separate location, verified end to end. This is our own disaster-recovery safety net; it doesn't replace your own service backups (those still live under backups), it just 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% — 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, not by history: build (services, databases, apps, yard), data & 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 (old links redirect), and 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 (comments and quotes handled, invalid lines reported, service-scoping respected), 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 — 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 (every old credential stops working, 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: 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 (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; 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. 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 — 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.

Safety first: 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 crashed since launch; 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. Move wallet credit between two projects of the same organization yourself — no support ticket, no workaround. On the portal wallet page it's a one-line form (amount + 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 — both ledgers update together or not at all — the source can never overdraw (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 — previously that combination could 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 / --wait-until healthy|routable blocks until what you asked for is actually true — 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 (no more re-deploy conflict), and bootload capabilities — and GET /v1/capabilities — hand 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 — the old version keeps 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.

First up: 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 (a connectivity probe; no customer data exposed, and every other isolation boundary held), and 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 — no more silently unreachable services 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. Rounding it out: 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: stop signals reach every guest in parallel with 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 — point any client or library at it, no proxy tricks. The portal shows your SPF / DKIM / 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 — 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 — no more timeouts on big volumes — 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 (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 (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 — DNS set, certificate hoisted, HTTPS answering.

Reliability got the same attention: internal services now declare the port siblings reach them on (bootload exposure <svc> internal --port 5432 — 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 🇫🇷

The big one: 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, not 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 — 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.