Changelog

What's shipping at Canner.

We've been live since early May 2026 and ship most days. The list below is hand-maintained — pulled from production deploys, not from a feed. Subscribe via RSS coming soon. For now, check back, or follow hello@canner.ca.

Want to know what's coming? See the roadmap for what's prioritized to ship next.

  1. A simpler Logs page, error emails you ask for, and cleaner tabs

    • The Logs page is now two views: Requests and App logs. Errors are simply the failed requests (pick Errors in Requests), and the overview's Server errors tile and a clicked chart bar open Requests filtered to that period. The live tail and the Deploys view are gone.
    • Error emails are now off until you ask for them. Each app gets one email, for the first error we catch, with a link to it; open it and switch on "Email me about new errors" to hear about new errors and regressions after that. An opened error also now shows its history over the period you came from, instead of always the last 7 days.
    • A time range you can set exactly. The Traffic & Memory chart and the Logs page now share one range control: the last hour, 6 or 24 hours, 7, 30 or 90 days, or a custom From and To. Clicking a chart bar fills that bar's From and To in on the Logs page instead of guessing a filter, and a bar older than the 7 days of kept requests no longer opens an empty list.
    • The chart can now draw 1, 5 and 15-minute bars for anything inside the last 7 days, and offers only the bar widths that make a readable chart for the range you picked (between 7 and 400 bars), opening on the one that gives about 48.
    • Tabs across the dashboard share one flat underline (the old one curled up at its ends), including the database pages.

  2. Errors, logs and deploy history, and a Traffic & Memory chart with every minute of the last week

    • Errors are grouped by what would fix them and tied to the deploy that caused them. The project's Logs page now has Errors, Requests, App logs and Deploys beside the live tail: see which deploy an error began in, with its commit, what changed, and whether it has come back since. Resolve or ignore an error; a resolved one that happens again is flagged as a regression. Errors are kept 90 days, requests and app output 7 days, on every plan.
    • Emails for a new error right after a deploy and for a regression, once each and at most one an hour per app. An optional "Explain this error" asks a model that runs on Canner's own server, so your logs never leave it; the quotes it gives are checked against your real logs. Agents can read all of it through six new MCP tools.
    • The traffic chart is now Traffic & Memory: requests above the line, memory below, with builds and crashes marked. Pick the period and the width of the bars, switch between requests and visitors, hide any series, click a bar to see its errors, and download the data as CSV or Excel. Traffic and memory are now captured every minute for the last 7 days (hourly history is kept as before), and latency is recorded as a histogram so percentiles are right at any bar width.
    • A build or release command that stops at a yes/no question no longer holds the deploy for 15 minutes. After about 20 seconds of silence at a prompt such as "Would you like to proceed? (y/N)", the command is stopped and the deploy fails with the question itself and what to add (its non-interactive flag, or a piped answer). Saving a command that is known to ask, like prisma migrate reset, artisan migrate or collectstatic, now warns you with the flag to use.
    • While a version builds, the top right of the project overview shows the build: its phase, how long it has run and the last line of its log. The status next to the project name says Queued, Building or Deploying instead of Live while it runs. If a release command stops at a yes/no question, the question and Yes / No buttons appear there too.

  3. Take down holds, a runtime-only variable scope, and migrations through the release command

    • Take down now holds. A taken-down project can only be started again by a deploy: not by a visitor, a domain check or a server restart. Its address answers 503 (“currently stopped”) instead of 404. The dashboard also says so when the request is refused for too many requests, instead of failing silently.
    • Variable scopes mean what they say. A production variable now reaches production deploys only; previews get variables scoped all or preview. Existing variables keep behaving as before (they are now scoped all). New: runtime only, for the running app on production deploys, never a build, the release command or a preview.
    • The owner login for migrations (DATABASE_URL_MIGRATE) now goes to the release command only, not to builds, and is a session connection so tools that use advisory locks work. It has its own switch on the database’s Access settings.
    • The project overview has an Auto-rollback switch. Turn it off and a deploy that fails to start stays stopped instead of rebuilding the last good commit.

  4. Sending domains verify themselves, and you can remove or change one

    • Canner Auth sending domains are now checked automatically: every few minutes for the first half hour, then about three times an hour, for 24 hours. You get an email when the domain is verified, or one email listing the records that were still missing if it never is. Check again still works at any time, and starts a new 24 hours after Canner has given up.
    • A sending domain can be removed from the app, which also lets you switch to a different domain. A half-finished setup is released at our mail provider, so the name is not left blocked.
    • The DNS record table shows each record’s purpose (DKIM or SPF) and the MX priority, which was missing, and has a Copy button on every name and value. The setup now says up front that you will need to add DNS records, and the troubleshooting advice no longer assumes a particular DNS provider. The guide has a full Send from your own domain section.
    • Resending the account verification email now says “Too many requests, please wait” when you have asked too many times in an hour, instead of a button that only said “Try again”.

  5. Passkeys for every member, API token expiry, and monitoring access for your database roles

    • An organization admin can require a passkey for every member (Organization, Sign-in security). It is off by default. While it is on, members open the organization only after signing in with a passkey, and anyone without one is asked to add one. API tokens are not affected.
    • API tokens can expire. New tokens made in the dashboard last 30 days to a year, and the API accepts expires_in_days up to 365. An expired token stops working like a revoked one.
    • On a dedicated instance, the roles your database owner creates in SQL now appear in the Roles list, and any role can be given pg_monitor (or pg_read_all_stats, pg_read_all_settings, pg_stat_scan_tables), which a database owner cannot grant on their own.
    • The pricing grid no longer lists named roles on every plan: they belong to the dedicated instance, as the documentation says.
    • API tokens can be restricted to specific projects. A restricted token acts only inside the projects you pick (no other project, billing, domains, members or tokens, and no MCP); the default stays organization-wide. Expiry is optional too, with one year as the default.
    • A start command per project: Settings → Build now lets you replace the command Canner detects (your start script) with your own, one line, run from your app's directory.

  6. Deleted files you can bring back, and a storage meter on the Files page

    • The Files page has a Deleted tab. A deleted file, or the older version of a file you uploaded over, can be restored for 30 days (1 to 365, set per project, never shorter than the project's database backup windows), or deleted forever to free the space at once. It also covers files your own code writes with the S3 credentials.
    • The storage meter on the Files page is now the same segmented meter as on the database pages, with files and deleted or older versions as their own segments.
    • File backups. A new Backups tab on the Files page takes scheduled or on-demand backups of a project's files: a list of every file with its version, size and sha256 that holds those versions so they are not purged, with no extra storage. Compare with now, restore (put back what is missing or changed, restore exactly, or copy into a folder to look first), verify by reading the files back against their sha256, and download a files manifest to check against the file references in your own database. Restoring brings a file back under its own name, so those references keep working without restoring the database at the same moment.
    • File backups can be copied off-site to your own S3-compatible bucket, the same destinations database backups use. The copy is plain files, each distinct file stored once under its sha256, with a readable manifest, so it survives the loss of the server and can be read without Canner. A restore or verification that finds a file missing here uses the off-site copy; deleting a backup, or erasing a file from backups, is mirrored there.

  7. Schema & policies: a file that says exactly what a backup holds

    • Each backup now records its schema & policies as a JSON file you can download next to it: tables and columns, indexes, constraints, row-level security, policies, grants, default privileges and the roles involved, with row counts and two fingerprints. No row data and no password hashes, so it is safe for an audit file. Add ?compare=live in the API to have it also state how the live database differs right now.
    • Test restores are stricter. A verification restore now compares the restored copy with that record and fails if a table, a column, a policy or a grant did not come back. Downloading a backup file, which did not work before, now does.
    • Pull-request previews can be turned off per project (project settings, or previews_enabled in the API). A preview runs a branch's code with the project's environment variables and its database, so a project holding live credentials should not build them: keep production on its own project with previews off, and previews on a staging project with sandbox credentials. Turning them off stops new previews and branch deploys, and can remove the ones already running.

  8. Backups that see everything: choose who backups run as

    • On a dedicated instance, a new Backups run as setting lets Canner read your databases as the instance superuser instead of the database owner. A table with forced row-level security hides its rows even from its owner, which made owner-run backups fail; the superuser reads them, and it never depends on the owner's password, so changing it in SQL no longer breaks a backup.
    • Restores come back with the same permissions. A superuser-run backup keeps your grants, default privileges and the roles your database uses (with their password hashes, encrypted), so restoring it in Canner, or a point-in-time restore, brings back row-level security, policies and logins without you providing anything. Test restores now check that every table that held rows still does, and you can download a roles file to restore on a server of your own.

  9. Static sites: compression and custom headers

    • Static sites are now served compressed. HTML, CSS, JavaScript, JSON, SVG, source maps and TTF/OTF fonts over 1 KB go out as Brotli or gzip, whichever the browser accepts. This covers plain static sites and the built output of Vite and similar projects.
    • Custom headers. Add a `_headers` file (the Netlify and Cloudflare Pages format) to set Content-Security-Policy, X-Frame-Options, Referrer-Policy and any other response header, per path. With Vite, put it in `public/_headers`.
    • Both apply the next time a site is deployed. See the static sites docs.

  10. Postgres, part two: your own roles, in-place upgrades, and a security check

    • Your roles, your rules. The named roles from the last update go further: on a dedicated instance your database owner can now create roles in SQL (groups, logins, grants, row-level security policies) and Canner doesn't track or second-guess them. A login you create that way connects through the pooler like any other, and you choose which login your app receives instead of the owner's. Groups and logins are in the dashboard and in `canner db roles`, with a role audit that shows what each role can actually do.
    • Upgrade Postgres without rebuilding anything. `canner db instance upgrade` moves a dedicated instance to a newer major version in place. Databases, roles, grants, policies and extensions carry over, connection strings don't change, and if anything fails the instance is left exactly as it was. The previous version is kept for seven days so you can go back, and point-in-time recovery starts a fresh window afterwards. Every database on the instance is offline for a few minutes while it runs.
    • A security and performance check on every database, on every plan. Run `canner db check` or open the new panel on any database. It reads the catalog, never your data, and flags permissive row-level security policies, functions anyone can run as their owner, views that bypass the rules, missing primary keys and indexes, and more. `--strict` fails CI on warnings.
    • Least privilege in one step. `canner db least-privilege` runs your app as a role that can read and write your data but cannot change the schema or touch a migration ledger, including one your first migration creates. The owner goes to the build only, as `DATABASE_URL_MIGRATE`, so your migrations still run.
    • No more guessing what is injected. The environment variables page now lists what Canner sets from your databases, with the password hidden, and warns you when a variable of your own is being overridden, with a link to turn auto-inject off.
    • Smaller fixes. Database clients that set `statement_timeout`, `lock_timeout` or `idle_in_transaction_session_timeout` when they connect now get through the pooler; it accepts them without applying them, so set timeouts on the role. The object storage docs now explain why `HeadBucket` returns 403 for project-scoped credentials and what to use instead. MCP gets three read-only tools: the security check, the role audit and an upgrade check (upgrading itself stays in the dashboard and the CLI). CLI 0.5.3 has all the new commands.
    • All of it is in the dashboard, the CLI (`canner db …`) and the API. See the Postgres databases docs.

  11. Pay for what you use: the Studio plan becomes add-ons

    • Two self-serve plans, Starter and Live, plus Enterprise by quote. Everything the Studio plan bundled is now an add-on you turn on by itself, so you never jump a whole tier to reach one feature.
    • New Compliance add-on, $29 a month: a signed PIPEDA / Law 25 Data Processing Agreement, a data-residency attestation, and your organization's audit log with export. It replaces the one-time $149 documents.
    • The pricing table now shows each add-on beside the row it extends: always-on apps, App RAM and Dedicated RAM, storage, dedicated Postgres and Compliance.

  12. Postgres mega-update: backups you control, point-in-time recovery, and a dedicated instance

    • Backups and recovery on your terms: schedule backups per database, keep them as long as you choose, copy them to up to five S3-compatible buckets you own, inspect a restore before it touches anything, and get alerts for failed or unverified backups. On a dedicated instance, restore any database to any moment in a 1-35 day window (point-in-time recovery), into a brand-new database.
    • A dedicated Postgres instance per project: your own server process with extensions (pgvector, PostGIS, pg_cron and more), workload presets and a maintenance window, named roles, metrics, slow queries and logs, logical replication out to your own subscribers, and following an external Postgres server live for a no-downtime migration. The recovery archive is encrypted with AES-256 and can be copied off-site to your own bucket.
    • One storage pool per organization: your plan's limit plus any 50 GB blocks covers databases, backups, the recovery archive, objects and Data Workshop datasets. Adding a database never raises it.
    • Add-ons, clearer: new App RAM ($4 per GB, pooled memory for an app) alongside Dedicated RAM ($19 per GB, guaranteed, the safer pick for Postgres and AI workloads). The performance block is retired. Every purchase now previews your new totals and the monthly price first, and charges only when you confirm.
    • All of it is in the dashboard, the CLI (`canner db …`), the API and MCP. See the Postgres databases and Plans & limits docs.

  13. Lightning Fast Builds on Canner's New 2026 Infrastructure

    • Canner now runs on dedicated hardware we operate ourselves — no shared virtualization layer, no other tenants competing for the same CPU. Every build, on every plan, runs on it.
    • The result: builds are running 4-6.5x faster than before, with no changes required on your end — same repo, same dependencies, same commands. We measured the same projects before and after the move to get that range. Some lightweight builds now finish in single-digit seconds.
    • Every domain, certificate, database, and environment variable carried over untouched. Read the full migration story at /blog/vps-to-dedicated-server-migration.
    • What changed: Canner's build and hosting infrastructure moved from shared, virtualized VPS servers to dedicated hardware that only Canner uses — the same kind of architecture change any team can make to fix inconsistent build performance, just handled for you.

  14. Heads up: the legacy *.app.canner.ca alias retires September 30

    • Every tenant used to get both a canner.app URL and a legacy *.app.canner.ca alias, whether or not the alias was ever used. Now only projects that existed before the July 2026 cutover (or that we've individually confirmed still need it) keep the legacy alias — and it disappears entirely for everyone on September 30, 2026. If you're still linking to a *.app.canner.ca address anywhere, switch to your canner.app URL before then. Affected owners have already been emailed directly.

  15. Object storage: recover from an accidental delete or overwrite

    • Every object storage bucket now keeps version history. Delete or overwrite a file by mistake, and the previous version is retained for 30 days before it's permanently cleaned up.
    • Recovery inside that window is a support request today, not yet a self-serve action — email us and we'll restore the version. Retained versions count toward your storage quota, so a churny bucket still can't grow without bound.

  16. If a project keeps crashing, we stop hammering it and tell you

    • A project that repeatedly fails to start no longer gets retried forever in the background. After several failed starts in a short window, Canner stops retrying, shows visitors a clear "waking up" page instead of a raw error, and flags the project in your dashboard with the reason.
    • Redeploying is the fix — a fresh deploy automatically clears the flag and resumes normal behavior. We also email your account once, the first time this happens, explaining what it means.

  17. Pick your monorepo's root directory instead of typing it

    • Connecting a GitHub repo now offers a Root Directory picker populated with real candidate paths detected from your repo — anywhere with a package.json, requirements.txt, go.mod, and similar build markers — instead of a blank text field you had to get right on the first try.
    • Available both when connecting a new repo and afterward from the project overview's source card, next to the branch and framework pickers.

  18. Account deletion now lists exactly what gets destroyed

    • Deleting a sole-member organization used to show one dense warning sentence. It now itemizes everything that goes with it — projects, API tokens, Canner Auth apps, compliance orders, Data Workshop datasets and queries, scheduled jobs, your Stripe subscription — and calls out that a purchased domain is held, not deleted.

  19. Resource add-ons — buy exactly the capacity you need

    • Four à-la-carte add-ons now sit alongside your plan: an extra always-on app slot ($4/mo), a performance block (4 GB RAM + 2 vCPU dedicated to one project, $69/mo — also unlocks ML/Rust runtimes for it), +50 GB of pooled object storage ($5/mo), and extra Studio team seats ($5/mo).
    • Performance blocks are assigned to a specific project from its overview page, so guaranteed capacity goes exactly where you need it instead of raising a shared ceiling. Add-ons layer on top of any paid plan — Starter shows the same panel as a preview of what upgrading unlocks.

  20. Deploy BoxLang — CFML apps on the JVM

    • BoxLang (boxlang.io) — the modern, CFML-compatible JVM language — now deploys straight from your repo. A box.json, server.json, Application.bx/.cfc, or a .bxm/.cfm template is all Canner needs to detect it.
    • No build step: the BoxLang MiniServer serves your source and compiles on the fly, box.json modules install from ForgeBox automatically, and proxy headers are trusted so datasources and sessions work behind the edge. Runs on Java 21; Live plan or above. Guide at /docs/other-runtimes.

  21. Deploy Java — Spring Boot, Maven, and Gradle

    • Java now deploys the same way as everything else. Push a Maven or Gradle project — Spring Boot included — and Canner detects it, builds the JAR, and runs it. No Dockerfile, no configuration.
    • The JDK is picked from your build: declare Java 17, 21, or 25 (via maven.compiler.release, java.version, or a Gradle toolchain) and Canner runs a matching Temurin runtime end to end — build and run alike.
    • Available from Starter up, on the same Canadian infrastructure as every other runtime. Full guide at /docs/other-runtimes.

  22. Choose your Postgres version — 17 or 18

    • When you provision a database you can now pick Postgres 17 (the default) or Postgres 18. Existing databases stay on the version they were created with; nothing changes unless you choose.
    • The Database tab shows the exact running version (for example, 17.9) so you know precisely what you're on, not just the major line.

  23. Team members, granular permissions, and dark mode

    • Invite people into your organization. Members sign in with their own account — passkey, password, or social — and you decide, per area and per project, whether each one can view or edit. Managing members stays admin-only.
    • Belong to more than one organization? An organization switcher in the sidebar moves you between them, and every plan limit is counted once per organization, never per person.
    • Seats are billed as you add them: an invitation beyond your plan's included seats adds a prorated seat charge, and removing a member releases it. Starter and Live include unlimited seats. Full guide at /docs/members.
    • Also new: dark mode across the whole dashboard. Follow your system, or set light or dark from the top bar.

  24. Background workers, and PHP 8.3 with Laravel

    • New: worker projects. A bot, a queue consumer, or any long-running process that isn't a web server can now run on Canner without a health check or a public URL — it just runs. Mark a project as a worker in its settings, or redeploy an existing one as one.
    • PHP 8.3 with a combined Laravel + Vite build: a Laravel app whose front-end assets are built by Vite now installs and compiles both sides in one pass, then serves through PHP.

  25. Audit log — an append-only record of what happened

    • Every meaningful action in your organization — deploys, member and permission changes, domain and billing changes — is now recorded in an append-only audit log, scoped to your organization, with who did what and when. Entries can't be edited or deleted.
    • Included on Studio and Enterprise, retained for 13 months, and exportable — the trail an internal review or a Law 25 accountability request asks for. Full guide at /docs/audit-log.

  26. Canner-issued GST/QST invoices

    • Every payment now comes with a proper Canner invoice — numbered, with GST and QST shown as separate lines and our Quebec registration numbers on it. Download any of them, anytime, from Billing.
    • Prices are shown before tax: GST and QST are added at checkout for new and changed subscriptions, at the rate your province requires (GST only outside Quebec, no tax outside Canada). Existing subscriptions keep their current total until their next plan change.

  27. New pricing: two clear ladders, and resources you add à la carte

    • Pricing is now two ladders. For builders: Starter (free) and Live ($9/month). For teams and businesses: Studio ($149/month) and Enterprise (quoted). You pick the ladder that matches why you're here, not a grid of overlapping tiers.
    • Studio is the team plan: 10 always-on apps, team members with granular permissions, the audit log, and compliance documents (DPA + Quebec residency attestation) included.
    • Resources are now add-ons, not a reason to jump a whole tier: an extra always-on app ($4/month), a performance block of 4 GB RAM + 2 vCPU ($69/month), +50 GB storage ($5/month), and extra seats ($5/month). Add what you need where you are.
    • Existing subscribers keep the price they signed up at. The former Dedicated tier is now Studio; nothing about a current plan changes without you choosing it.

  28. Passkeys, social sign-in, and Canner Auth

    • Sign in to Canner with a passkey — your fingerprint, face, or device PIN. Add one from Account; it then becomes the expected way in, and we email you if anyone gets in without it.
    • Google and Microsoft sign-in, linkable from your account page.
    • See every device you're signed in on, and sign any of them out.
    • New: Passkey (Canner Auth) — add passkey sign-in to your OWN app without building a user database. Available on every plan, including the free tier.

  29. Node.js 24 is now available

    • You can now build and run your app on Node.js 24 (24.18.0 LTS) as well as Node.js 22. Pick the version under Node.js version in your project settings; Node 22 stays the default, so nothing changes unless you switch.
    • The version applies to both the build and the running app, so a project that needs Node 24 features gets it end to end — not just at compile time.
    • Switching versions triggers one fresh install on your next deploy. Native dependencies are compiled for a specific Node version, so cached ones can't be carried across — after that first build, caching resumes as normal.
    • If your package.json sets an engines.node range, the build now tells you exactly which versions are available instead of failing on a version you can't select.

  30. Your app now lives at your-project.canner.app

    • Your app now gets a canner.app address instead of app.canner.ca — for example, my-project.canner.app. It switches over on your next deploy; until then nothing changes.
    • Your old address keeps working, permanently. Every app answers on both, so existing links, bookmarks and QR codes are unaffected. There's nothing you need to do. (Update, September 9, 2026: this turned out not to be permanent after all — see that entry for the *.app.canner.ca retirement.)
    • Why: browser safety systems judge an entire domain at once. Hosting customer apps under canner.ca meant one abusive page could affect every other app's address — and in July, it did. Customer apps now live on their own domain, so that can't happen again.

  31. Save your app straight from your AI builder — remote MCP + scoped tokens

    • New: a remote MCP server at https://api.canner.ca/mcp. Browser-based AI app builders — Lovable, Bolt, v0 — connect to a Model Context Protocol server by URL, so you can now point one at Canner, authenticate with an API token, and tell your agent "save my app to Canner." It creates a project and deploys your code onto Canadian infrastructure, from the chat.
    • New tools: canner_create_project and canner_save_app. The agent sends your project's full source directly (no repo required) and Canner builds and hosts it. Thirteen MCP tools in all; @canner-ca/mcp for desktop agents (Claude Desktop, Cursor, Claude Code) now proxies the same endpoint.
    • New: scoped API tokens. Mint a token limited to project + deploy access — no billing, no token management — so a credential you paste into a third-party builder can't do more than deploy. Existing tokens are unchanged and keep full access. See /mcp to get started.

  32. Caching, leveled up: a native Astro provider, draft mode, and stale-while-revalidate

    • New: a native Astro 7 cache provider. @canner-ca/astro-cache now plugs Canner into Astro's built-in route caching as a first-class provider — the same Astro.cache.set() API you'd use on Netlify, Vercel, or Cloudflare, pointed at Canner. Configure it once and cache per route, with tag- and path-based purging through one token.
    • New: draft mode. Preview unpublished CMS content on its real URL without purging what everyone else sees — a request carrying your project's bypass secret renders fresh from origin while the public keeps the cached page. Carry the secret in a cookie, a ?__canner_bypass= link, or an X-Canner-Bypass header; turnkey helpers ship for Astro, Next.js, and Nuxt.
    • New: stale-while-revalidate. Past a page's TTL, Canner serves the stale copy instantly and refreshes it once in the background — so no visitor ever waits on a cold render. Add stale-while-revalidate to your Cache-Control (or swr to the helpers) to turn it on.
    • Also: invalidate by URL (not just tag) — send {"paths":["/blog/post"]} to the purge endpoint. Caching is now documented as what it is: framework- and CMS-agnostic, with DatoCMS as one example among any. Full guide at /docs/caching.

  33. Scheduled SQL queries — run SQL against your databases on a cron

    • New: scheduled SQL queries. Write SQL, set a cron schedule, and Canner runs it against your project databases in Montreal — reading and writing them by name (project.schema.table), joining across projects, and writing results straight into your Postgres. No external ETL tool, no data leaving Canada. It's the SQL counterpart to scheduled jobs (which POST to a webhook). Available on every plan under Compute → Scheduled queries; full guide at /docs/scheduled-queries.
    • Each run is isolated: an in-memory engine with a per-query memory cap and timeout, the local filesystem disabled, and reach limited to databases your own account owns. Run history, run-now, pause/resume, and cancel are all in the dashboard.
    • Security hardening: Data Workshop queries now run with the local filesystem disabled across the board, closing off host-file access from user SQL.

  34. Real documentation, and a Live price that reflects what it is

    • A full docs site is live at /docs: quickstarts for every supported framework and runtime (Next.js, Vite, Astro, Node, Python, Go, Ruby, PHP, Rust, static), guides for domains, databases and environment variables, and a troubleshooting page that decodes the exact error messages you might see in a build log. Fully bilingual.
    • Live is now $9/month or $99/year. Existing Live subscribers keep their original price — this applies to new subscriptions only. Starter stays free, Dedicated stays from $29.

  35. Simpler pricing: Starter, Live, and usage-metered Dedicated

    • Three tiers instead of four. Starter is free and sleeps when idle; Live is a flat $4.90/month for always-on hosting, custom domains, and ML; Dedicated is usage-metered from $29 and scales as far as you need.
    • Dedicated bills fairly: you pay for memory or storage — whichever you lean on more, never both — so you only ever pay for what you actually use.
    • Machine-learning Python (PyTorch, TensorFlow) and Rust now run on Live, not just the top tier. Compliance documents and audit-log export are included on Dedicated.

  36. A documented REST API, an OpenAPI spec, and an MCP server for AI agents

    • The Canner API is now a proper REST surface under /v1, described by an OpenAPI 3.1 spec with an interactive reference at api.canner.ca/docs. Manage projects, deployments, domains, databases, environment variables, and billing from your own code. A new developer guide lives at canner.ca/developers.
    • Consistent error responses (a stable code, a message, and a request_id), rate-limit headers on every response, and keyset pagination on the list endpoints. Existing dashboard and CLI paths keep working unchanged.
    • New @canner-ca/mcp: a Model Context Protocol server that gives AI agents — Claude Desktop, Cursor, and others — native tools to deploy and manage your projects. Zero dependencies, in keeping with Canner's clean supply chain. See canner.ca/mcp.
    • The @canner-ca/cli gained a --json output mode for scripts and agents, plus new token, env, and domains commands.

  37. Deploy Python, Go, Ruby, PHP, and Rust — not just Node

    • Python now deploys the same way as everything else, with FastAPI, Flask, Streamlit, Gradio, and Django detected automatically. Drop a Gradio or Streamlit AI demo and get a live URL.
    • Go, Ruby (Rails, Sinatra), PHP (Laravel, Symfony), and Rust join the list too — no configuration, automatic detection.
    • More JavaScript frameworks recognized out of the box: Angular, Create React App, Gatsby, and Docusaurus, plus full-stack apps that run their own server.
    • Machine-learning Python (PyTorch, TensorFlow) and Rust are available on Pro and Enterprise.

  38. Enterprise plan, compliance documents, and a French blog

    • New Enterprise plan with a dedicated server, priority support, and a 99.9% uptime commitment.
    • A data processing agreement and a Quebec data-residency attestation are now available as one-time add-ons — included on Enterprise.
    • The full blog is now available in French, and the pricing page has a clearer side-by-side comparison.

  39. Response caching with targeted purge

    • Opt-in tag-based HTTP caching, served from Canner's own infrastructure in Quebec — not a foreign edge network. Available on every plan.
    • A headless-CMS publish can purge exactly the affected pages via a per-project webhook. Cache hit ratio is shown on each project.

  40. Stronger build isolation

    • Every build runs fully isolated under its own identity, with install scripts and network access locked down by default. Build logs now clearly flag an out-of-memory build instead of a generic failure.

  41. Data Workshop — SQL analytics on your uploads

    • Upload CSV, Parquet, or JSON and run standard SQL over it in milliseconds, right from the dashboard. Included on every plan, with per-tier storage and query limits.

  42. Drag-and-drop uploads and a command-line tool

    • Deploy without Git: drag a folder or a .zip onto the homepage, or upload from the dashboard. A static site (a folder with an index.html) deploys instantly, with no build step.
    • New @canner-ca/cli: run npx @canner-ca/cli deploy from any terminal — including inside Cursor — to ship the current directory.

  43. Pricing: free Starter, .com added to free domain offer

    • Starter is now a free plan, not a 30-day trial. Resources on Starter are pooled across free accounts and deprioritized when paid builds are queued.
    • Basic and Pro charge immediately on signup — no 30-day trial. What you sign up for is what you pay starting day one.
    • Free domain offer expanded to include .com: Basic includes .com or .ca on monthly, plus .quebec on annual; Pro includes .com, .ca, or .quebec on either interval.

  44. Domain checkout: CIRA CPR registrant form + Quebec acknowledgment

    • New registrant form on the domain checkout modal, with proper CIRA CPR (Canadian Presence Requirements) dropdown for .ca registrations.
    • Quebec acknowledgment step for .quebec domains. Friendly 409 copy when the requested name was registered minutes earlier by another customer.

  45. Yearly billing toggle + free .ca / .quebec domain credit

    • Billing page now offers monthly and annual intervals. Annual saves two months versus monthly.
    • Basic annual and Pro (either interval) include a free .ca or .quebec domain registration, applied at checkout.

  46. More reliable cold-start, wake, and preview deploys

    • Idle projects sleep and wake automatically on the next request — no cold-start surprises. Live runtime logs and pull-request preview deployments now work consistently.

  47. Per-project metrics, preview deploys on PR, per-tenant systemd, public status page

    • Per-project hourly traffic metrics with status breakdown, visible as a chart on the project page.
    • Preview deployments on pull requests. Each PR gets a per-branch runtime at <branch>--<slug>.app.canner.ca, torn down when the PR closes.
    • Each project now runs as its own isolated system user, for stronger separation between tenants.
    • Public status page at canner.ca/status, server-rendered with a 10-second platform-side cache.

  48. Stripe billing, custom domains with auto-TLS, generic frameworks, API tokens

    • Stripe billing wired end-to-end. Add a card and subscribe to a paid plan in a few clicks.
    • Custom domains with automatic Let's Encrypt TLS issuance via Caddy. CNAME your domain and the certificate appears in seconds.
    • Generic framework detection: Next.js, Vite (React, Vue, Svelte), and plain Node.js applications all build and serve without configuration.
    • API tokens (cnr_…) for programmatic access. Retry, cancel, and rollback endpoints on every deployment.
    • Bilingual French / English dashboard. Account deletion (cancels subscription, drops all tenant DBs and runtimes).