v26.10.2-rc.2

metrics for postgres databases (#118)

* enable pg metrics scraping

* database metrics graphql api

* database metrics in dashboard ui

* update docs with db metrics

* update docs

* make metrics tab consistent across service and database

* update volume usage to the same look and feel

* new screenshot with more context

v26.10.1

Over the last weeks the hosted Lucity platform at lucity.cloud has seen growth as it never has before. Hundreds of accounts signed up per day, to the point where we had to temporarily disable sign-ups to keep the platform stable. So, naturally this growth exposed some growing pains and v26.10.1 is here to relieve some of those.

It's highlight feature is that now all workloads deployed to Lucity are fronted by a global edge network, powered by bunny.net. This alleviates the platform from networking strain, since connections are opened at the edge and pooled to reach Lucity. It also gives us more control about bandwidth limits per workspace and enables exciting new possibilities for CDN features in the future.

The next growing pain the surge exposed is scheduling of workloads. Previously CPU and memory requests were statically calculated based on the user-configured limits of the service. Naturally this was very inefficient, since a user could set a 16gb memory limit to a web server that actually just used a couple 100mb. That resulted in very inefficient scheduling. To the point where no new workloads could be scheduled, even though the actual resource usage was well below the total cluster capacity. With v26.10.1 Lucity calculates memory and CPU requests dynamically, based on what the workloads actually use. The user only configured the limits, which essentially act as a lever to limit runaway processes from creating a massive bill.

Check out the list below to get an overview of all changes that come with this release.

Edge network

• Web traffic to your services now enters through a global edge network. Visitors connect to an edge location near them, and the edge keeps a pool of connections open to the platform, so handshakes happen close to the user and the platform's load balancer gets a lot calmer. (#97)
• Generated hostnames and custom domains both go through the edge, with the certificates they already have. There is nothing to change in your DNS. (#97)
• Nothing is cached. Every request still reaches your app, so dynamic pages, cookies, and per-user responses behave exactly as before. WebSockets pass through too. (#97)
• Heads-up if your app reads client IPs: the visitor's address is the first entry of X-Forwarded-For and also arrives as X-Real-IP. If you count proxies from the right (for example SvelteKit's XFF_DEPTH), bump it from 1 to 2. (#97)
• Each workspace has fair-use limits at the edge: 1 TiB of traffic per month and 500 concurrent WebSocket connections. (#97)

HTTPS everywhere

• Plain http:// requests now redirect to https:// for generated hostnames, custom domains, and the platform itself (dashboard, docs, and sign-in). (#104)
• The redirect is a permanent 308 that keeps the path, the query string, and the request method, so a POST stays a POST. (#104)
• A domain that redirects to another one (say, your apex to www) now lands on the https:// target in a single hop instead of two. (#104)
• It's plain Gateway API config in your app's chart, so it comes along when you eject. (#104)

Resources

• CPU and memory reservations now follow real usage. Building on the groundwork from the last release, the Vertical Pod Autoscaler sizes each service's reservation from what it actually uses and adjusts it on the running instance, usually without a restart. Your limits stay exactly where you set them; the cluster just stops holding idle capacity, so deploys and scale-ups find room faster.

CLI and MCP

• Switching workspaces in the CLI works again. lucity login also forgets a remembered workspace you're no longer a member of, and lucity account lists your workspaces with the active one marked.
• Agents no longer build a new service twice. add_service already starts the first build, and the MCP server now says so and hands back the build to watch instead of nudging the agent to deploy.
• A change made while an earlier rollout is still applying now comes back as a clear "retry in a few seconds" instead of a cryptic error.
• The deploy skill follows the new secret rules end to end: it generates app secrets like SECRET_KEY_BASE itself, asks you to add third-party keys in the service's Variables tab instead of pasting them into the chat, and hands you the steps for bulk database imports to run in your own terminal.

Platform notices

• The dashboard and docs can show a banner for maintenance windows, incidents, or other news, so you hear about platform events right where you already are. Close it and it stays closed until the message changes. (#103)

Self-hosting

• Set the banner with banner.message, banner.severity (info, warn, or danger), and banner.dismissible in the lucity chart values. Changes show up within about a minute, no rebuild or restart. (#103)
• HTTPS redirects are opt-in per listener: set httpsRedirect: true on the HTTP listeners in the lucity-infra gateway values, point the platform routes at the HTTPS listeners with routes.sectionName (plus sectionName on the identity provider and analytics routes), and set GATEWAY_HTTPS_LISTENER for workloads. Upgrade lucity-infra before lucity. (#104)
• The edge network is optional. Without its settings, traffic reaches your gateway directly, exactly as before. (#97)
• The CertExpiringSoon alert now only fires when a certificate is close to expiry and hasn't been renewed, so short-lived certificates no longer keep it firing forever. (#104)

v26.10.1-rc.2

add insecure option to internal registry dial

v26.10.1-rc.1

fix graceful shutdown message

v26.9.2

This release does not add shiny new feature but instead focuses on polishing the existing experience. The standout change is a completely and carefully overhauled docs section. Besides that the MCP gained some important privacy improvements and we did some tweaking to make the platform more stable.

Docs

• Entirely new docs, now part of the landing page. A quickstart with screenshots takes you from a fresh account to a live app on its own domain, with a PostgreSQL database and an object storage bucket attached. (#98)
• Framework deploy guides, plus dedicated pages for services, deployments, builds, variables, domains, PostgreSQL, Redis, object storage, volumes, projects, and workspaces. (#98)
• A CLI reference generated straight from the CLI's own help texts, so the two can't drift apart. (#98)
• Use cases and comparisons now live in their own sections. (#98)

Eject

• An ejected project now ships with a README and a build.sh that rebuilds your source-built services with Railpack (pinned to the version Lucity uses) and pushes them to a registry of your choice. Leaving got a lot less work. (#98)

MCP and CLI

• The Lucity MCP server never puts secret values into the model's context. Agents can no longer read variable values or database and bucket credentials, and secrets in log output are masked. (#99)
• lucity token prints a valid bearer token, handy for scripting against the API. (#98)
• Every CLI command has its own --help with usage and examples, for example lucity login --help. (#98)

Object Storage

• Creating the first bucket in a brand-new workspace no longer fails. The platform now gives fresh bucket credentials time to propagate before using them. (#96)

Self-hosting

• Platform routes accept extra response headers through routes.responseHeaders, for example an X-Robots-Tag that keeps a staging instance out of search indexes. (#98)
• Two fewer settings: GITHUB_OAUTH_CALLBACK_URL and OIDC_CLIENT_SECRET are no longer used. GitHub sign-in goes through the identity provider, and the dashboard signs in with PKCE. (#98)
• The docs and landing pages link to the dashboard on the same host, so a self-hosted instance no longer sends visitors to lucity.cloud. (#98)
• The infra chart now ships the Vertical Pod Autoscaler from the Kubernetes autoscaler project. (#100)

Reliability & operations

• The platform now learns how much CPU and memory each service actually uses. It's the groundwork for sizing reservations from real usage instead of a fixed share of your limit, so deploys stop waiting on capacity that sits idle. Nothing changes for your services yet. (#100)

v26.9.1

Over the summer lots has happened at Lucity and this packed release shows that.

This release brings automated, zero-config CVE vulnerability scanning to every service on Lucity. Furthermore it ships Postgres Backups with Point-in-time-Restore (PITR) and allows custom domains to configure redirects.

Vulnerability Scanning

• Every service built from source now has a vulnerability report in its Security tab, right next to the leaked-credential findings, covering the exact image that is running. Scans are powered by Trivy running inside Zot, the platform's own registry, so your images never leave the cluster to be scanned. (#64)
• Findings are summarized by severity from critical to low and split between operating-system and application packages. Each one lists the installed version, the version that fixes it (or a clear "no fix available"), where the package lives in the image, and a link to the advisory. (#64)
• The report is read live from the registry, whose vulnerability database refreshes every couple of hours, so newly published advisories show up against your running image without a redeploy. (#64)

Database Backups & Point-in-time Recovery

• Every PostgreSQL database is now backed up continuously: weekly base backups plus continuous write-ahead log archiving, so you can restore to any moment within the 30-day retention window, not just to the last snapshot. Powered by CloudNativePG and Barman Cloud. (#73)
• A new Backups tab on every database shows the restorable window on a recovery timeline, lists the backup history, and lets you take a manual backup on demand. (#73)
• Restoring never touches the source database. Picking a point in time creates a second database holding the data as it was at that moment, running alongside the original until you decide what to do with it. (#73)

Custom Domains

• A custom domain can now permanently redirect (301) to another domain on the same service, path and query included. The classic case: send example.com to www.example.com (or the other way round) without shipping a redirect in your app. Available in the dashboard and via redirect_to in the MCP server's add_domain tool. (#92)
• Apex domains that are served directly now point at the platform with an ALIAS record instead of a fixed IP address. The dashboard tells you when your DNS provider needs ALIAS, ANAME, or CNAME flattening for that, and offers the redirect as the way out when it does not. Existing apex domains keep working as they are. (#92)
• The platform-wide ceiling of 64 custom domains is gone. Each domain now gets its own listener through the Gateway API ListenerSet on Cilium, rendered by the app chart, so your domains eject together with the rest of your release. (#76)
• Domain verification is more patient with flaky DNS: every authoritative nameserver is tried in turn with its own short timeout, so one slow or unreachable nameserver no longer leaves a domain stuck in an error state.

Prebuilt Images & Volumes

• Image-based services can now run under a configurable user ID, and the ownership of mounted volumes is derived from it. Images like mysql that used to crash trying to chown their data directory now start cleanly, no custom entrypoint required. (#65)
• Volumes now mount as genuinely empty directories, which fixes applications (looking at you again, MySQL) that refuse to initialize into a directory containing a stray lost+found folder. (#66)

Variables

• Lowercase variable keys are now allowed, and the dashboard no longer displays every key as uppercase.
• The platform-provided PORT and HOST defaults now yield to your own values, so you can override them like any other variable.
• Variable input is validated more strictly: keys are length-checked and references must point to a variable that actually exists, so a typo fails fast instead of producing a broken rollout.

Redis

• Deleting a Redis store now also removes its volume, instead of leaving an orphaned disk behind.

CI & CLI

• CI deploy tokens can now read and set service variables for the services connected to their repository, so lucity vars works from your pipeline.
• CI deploys are no longer restricted to a service's tracked branch: any ref can be deployed from your workflow.
• The CLI is now distributed as a Homebrew cask.

Dashboard

• Buttons across the dashboard now show loading states while a change is applied, instead of leaving you guessing whether the click landed.
• Services can be given up to 16 GiB of memory from the settings tab.
• Removed the project resource quota sliders, which never actually worked.
• Workspace settings now renders correctly for accounts that do not have a plan yet.

Reliability & operations

• Platform alerting got sharper: out-of-memory kills, a stalled metrics pipeline, node CPU and memory pressure, and load balancer saturation now page the team, and a few rules that fired on gaps in the data were tuned to stop crying wolf.

v26.9.1-rc.1

redirect (301) for custom domains (#92)

* add recirectTo to lucity-app chart

* update mcp server with redirectTo field on custom domains

* include new redirect_to in skill references

* bump fallback version

* implement redirect in conductor

* redirect ui in dashboard

* improve mcp tool description

* simplify add_domain description in deploy skill

* consolidaate validation logic in Validate function

* add concise package docs

* fix redirect

v26.7.2

In this release object storage buckets got some love: Lucity now ships with a built-in file browser for buckets and they can now be configured to be publicly accessible via a *.storage.lucity.app domain served over our CDN. This is very useful if you want to host images or other static assets for your website. Newly available are also configurable HTTP health checks on services. This allows rollouts to be genuinely zero-downtime. And lastly the CLI got a bit extension and the dashboard now renders service logs in color! ✨

Check out the list below for all changes.

Object Storage

• Browse a bucket's contents right in the dashboard: list files and folders, upload, download, delete, and create new folders. No separate S3 client, no cloud console. (#58)
• Flip a bucket to public read with a single toggle. Lucity fronts it with a CDN and serves it under storage.lucity.app, so anonymous reads never touch your private credentials. (#53)

Deployments and Rollouts

• Point a service at an HTTP health endpoint and Lucity gates traffic on it instead of a plain TCP port check. A deploy only shifts traffic once your app actually reports healthy, so rollouts are genuinely zero-downtime. (#54)

CLI

• Manage databases from the terminal: lucity db create, list, credentials, expose, unexpose, and delete. (#55)
• Manage variables from the terminal: lucity vars list, available, and set. (#55)
• See what's running at a glance with lucity status. (#55)
• Set CPU and memory when you create a service or database, from both the CLI and the MCP server, instead of provisioning first and resizing after. (#56)

Databases

• Connection URLs now use the postgresql:// scheme, which more tools and drivers accept out of the box.
• The Connection tab is clearer about reachability: a dedicated internet-access card and plain-language labels for private, public, and custom-domain endpoints. (#52)

Dashboard

• Build and service logs are now colorized, so warnings and errors are easy to pick out at a glance.
• Service nodes show the source repository they deploy from, and the Variables tab got a cleaner layout. (#52)