What changed, and when.

• Change your password from your account page. Account → Password lets you set a new password with your current one, or email yourself a link to set one if you sign in with a code or have forgotten it.

• Chat with us on candordeploy.com. The chat bubble on the site now reaches the Candor team directly — the same inbox that answers the portal’s Help chat.

• Two-factor sign-in. Signing in now asks for a code from an authenticator app. The first time, the sign-in page shows a QR code to set one up.

• Resizing a database’s memory now takes effect. It used to update the number shown and the memory pool, but never the running database. The database now restarts on the new memory straight away — a brief interruption while it comes back up; its data is untouched.
• Supabase Studio is findable. With the full stack on, a Supabase database’s connection details now include Studio’s address and its sign-in (user supabase and the generated password, masked until revealed). Studio was there and protected all along; nothing told you where it was or how to get in.

• Signing out of the portal now ends your session on our side too, so a copy of the session cannot be used afterwards.

• Sign in on Candor’s own pages. Signing in, creating an account and resetting a password now happen on deploy.candorhost.com itself — with your email and password, or a six-digit code by email — instead of a separate sign-in site. Signing out and coming back always asks for your credentials.

• Database connection strings are hidden for apps deployed from a repo too. The previous release hid them when you attached a database by hand; this covers the databases Candor provisions for you when it deploys a repository, which is how most apps get one. MySQL’s generated passwords are hidden as well. Your app still receives all of them unchanged.

• A free project can actually run a database now. Raising the memory allowance was half of it; the storage allowance was still too small for a database’s disk, so one would be created, reported as ready, and never actually start. Both fit now.

• Your database URL and generated secrets stop being readable back. A database connection string carries its password, and a {generate: …} value in your .candorfile is minted by us and exists nowhere else — both are now treated as secrets, so the environment screen and the Claude connector show the name and withhold the value, exactly as they already did for anything you marked secret yourself. Your app still receives them unchanged, and a plain literal from your .candorfile stays readable, since it is sitting in the repository you committed.

• Claude stops asking permission to look things up. Every tool the Candor connector exposes now says whether it only reads or actually changes something, so asking what you have deployed, whether a build finished, or why one failed just answers — while setting an environment variable or redeploying still asks first, because those change a running app.

• The free plan runs an app and a database now. It was 512 MB, and a database always takes 512, so a free project could hold one or the other and a deploy that wanted storage was refused outright. The pool is 768 MB, and an app onboarded alongside a database is sized to fit beside it instead of failing. Existing free projects get the extra room automatically; nothing to do.

• Your billing page now shows your credit and your card. The launch credit — and any credit our team has added — was applied to your account but shown nowhere; the organization’s billing page now says how much is left, and which card (brand, last four digits, expiry) your invoices charge. An organization with no card yet is told what adding one unlocks.

• $100 in free credit, on us, when you start. Every new account gets a one off $100 credit the first time it puts a card on file — a launch special, not a trial: nothing expires, nothing switches off, and the credit simply draws down against your invoices until it is gone. One per account rather than per organization, so it is the person we are welcoming, not the number of workspaces they create.

• Connecting Claude or ChatGPT to Candor works again. “Add Candor” from claude.ai, ChatGPT or Claude Code sends you to the same sign-in the portal uses, then asks which project the assistant may deploy to, and you’re connected — no token to copy. The old consent screen still expected the retired client area, so nobody could get past it.
• Organizations. Your workspace is now a project inside an organization, and you can invite people to it by email with a role — owner, admin, developer, viewer or billing. Roles inherit from the organization down to each project and each app, and can be overridden for one project or one app when somebody should have more (or less) there than everywhere else. An invitation can be scoped that way too: invite a contractor to one app and one app is all they can reach. Everything you had is already inside an organization we made for you, and you own it.
• Billing belongs to your organization, not to one person’s account. The card on file, the plan, the invoices and the payment emails all attach to the organization now, so a colleague leaving does not take the billing with them, and anyone you give the billing role can handle the card and the plan without also being an owner. Payment emails — card declined, workspace paused, payment received — go to every owner and every billing member, and to nobody else. One card and one subscription cover every project in the organization: usage is billed once, and each plan you have projects on appears as a single line on the invoice with the number of projects on it. Usage is priced at your organization’s highest plan — an organization with a Studio project is charged for usage at Studio’s rate and gets Studio’s included usage across every project in it, so a project still on Free rides on the better deal rather than dragging the rest down to the worse one. Move a project up and the rate follows it the same day, with no charge for the change itself; move the last such project away and it comes back down.
• You can now put the card where the bill is. Adding or replacing a payment method happens on your organization’s billing page, not on a personal account page — so if you run two organizations, each one holds its own card and its own invoices instead of both quietly charging the first one. If you would rather have a card per project, choose per-project billing when you create the organization: each project then has its own billing page and its own card, and adding one starts that project billing straight away with its full spending headroom while the rest of the organization is untouched. The choice cannot be switched once billing has started. Plan changes and spend budgets live on the same pages, one project at a time, and your organization’s billing page shows what each project used this month, so a single invoice line still tells you where the money went. Nothing changes for an existing account: the card you already have is the card your organization already uses, and the old account billing page keeps working for one more release.
• If you call the API directly: a workspace is created at POST /v1/orgs/{slug}/projects now. The old POST /v1/workspaces answers 410 Gone and names its replacement. Your existing CLI token keeps working — it was migrated to a token scoped to the project it already reached.

A deploy could build fine and then never come up — and sit there saying “deploying” until you gave up on it. Now we diagnose it and say so: the container exited immediately, or it crashed on startup, or it never became ready, with the exit code and the last lines of its output.

We also stopped requiring you to know your start command. We detect it from your project, tell you what we detected, and if we genuinely cannot work it out, we say that plainly rather than guessing and failing strangely.

Push to any branch other than the one your service tracks — or open a pull request — and Candor Deploy builds that commit at its own URL. Production is untouched. Pushing again updates the same URL, so a link you paste into a pull request keeps working.

Previews get your production environment variables except the ones you marked secret, which are never copied into a preview. Give previews their own values under Environment → Preview.

They clean themselves up: a preview disappears when its pull request closes, when its branch is deleted, or after seven days with no pushes. Your plan includes a set number at a time, shown on the Previews tab, and each one runs in 256 MB.

A Protection tab on every app and static site. Set a per-visitor request rate, or allow/deny specific IPs and ranges. Changes apply at our edge in seconds — no redeploy, no restart, no downtime.

Being straight about what this is: edge rate limiting and IP filtering. It is not a WAF, and we will not call it one. Blocked requests show up as 4xx on your Analytics tab so you can see it working.

Apps behind our edge were receiving an internal cluster address as the client IP rather than the visitor’s real one. Anything you built on the client address — rate limiting of your own, geo lookups, audit logs, abuse handling — was working from the wrong value.

Fixed at the edge with no downtime. Your app now sees the visitor’s actual IP, and so do the new rate limits and IP rules.

Add a cron schedule and a path, and we call that path in your app on time, every time. Run history and a run-now button are in the portal, so you can see what fired and when instead of guessing.

Requests carry a header secret so only we can trigger them, and they go to your app’s internal address — never through the public internet. How many you get is published on the tab, not discovered when one silently stops.

Logs were a wall of raw text. They now parse into rows with timestamps and levels, filter by level, search as you type, and live-tail. Structured JSON logs are unwrapped so you read the message, not the envelope.

Separately, a project can serve every one of its services under one domain, with each service answering on its own path. Your frontend and your API on the same origin, which is what most apps want and what removes a class of CORS problems entirely.