DBaaS Postgres: storage autoscaling and backup browser
dbaaspostgresql
2026-07-27
By Thalassa Cloud
Two updates for DBaaS Postgres: automatic storage expansion and a backup file browser in the Console. Both are available now.
Storage autoscaling Database volumes can now grow automatically. When enabled, the platform monitors disk usage and expands the volume once it crosses your configured threshold.
You can enable this in the Console, via the CLI, or through the API:
Setting Description Notes Maximum Storage (GB) Upper limit the volume may grow to Must be at least 1 GB Scale at Usage (%) Utilisation threshold that triggers a scale-up Recommended: 80% (keeps 20% free) Increase by (%) How much to grow relative to current size Default: 10% Max Increase per Step (GB) Cap on how many GB are added in a single scale step Default: 100 GB The screenshot below shows the autoscaling configuration panel.
Two updates for DBaaS Postgres: automatic storage expansion and a backup file browser in the Console. Both are available now.
Storage autoscaling Database volumes can now grow automatically. When enabled, the platform monitors disk usage and expands the volume once it crosses your configured threshold.
You can enable this in the Console, via the CLI, or through the API:
Setting Description Notes Maximum Storage (GB) Upper limit the volume may grow to Must be at least 1 GB Scale at Usage (%) Utilisation threshold that triggers a scale-up Recommended: 80% (keeps 20% free) Increase by (%) How much to grow relative to current size Default: 10% Max Increase per Step (GB) Cap on how many GB are added in a single scale step Default: 100 GB The screenshot below shows the autoscaling configuration panel.
Until now, the default way to authenticate tcloud was a Personal Access Token (PAT): create one in the Console, paste it into tcloud context create, and hope it never ends up in shell history, a dotfile, or a shared screen recording. That works for automation, but it is a poor default for engineers who just want to manage clusters from a laptop.
With tcloud v0.20.0, browser-based OIDC login is the default.
Every API call in your Thalassa Cloud organisation leaves a trace. Audit logs record who did what, when, and from where - VPC changes, Kubernetes cluster updates, KMS crypto operations, secret access, and failed authentication attempts. That trail is essential for incident response, access reviews, and compliance evidence.
Audit logging is enabled by default for every organisation. Entries are immutable: they cannot be modified or deleted through the API. You can browse logs in the console or query them via the audit API, but for compliance archives, SIEM ingestion, or periodic security reviews you often need a bulk export.
Ingress controllers have served Kubernetes well for years, but with ingress-nginx now being end-of-life, many teams are re-evaluating their north-south traffic strategy. This is a good moment to move to the Kubernetes Gateway API. kgateway implements Gateway API model with Envoy as the data plane.
This post walks through installing kgateway, exposing a sample app, and applying Thalassa-specific load balancer settings as a future-proof alternative to legacy Ingress-based setups. For the full command reference and troubleshooting section, see the Gateway API with kgateway guide in our documentation.
Teams running workloads on Thalassa Cloud still had to host DNS with a separate provider. For organisations that use Thalassa for European data sovereignty, that left domain records outside the platform.
We heard from several customers that they prefer managing infrastructure and DNS through a single vendor: the same console, API, and audit trail they already use for VMs, Kubernetes, and load balancers, rather than maintaining zones at a third-party DNS service.
Teams running workloads on Thalassa Cloud often still store credentials with a separate secrets service. Some run OpenBao or HashiCorp Vault themselves — which works, but adds operational overhead on top of the application stack: deployment, upgrades, backup, and ongoing monitoring. Others rely on another third-party tool or vendor. For organisations that use Thalassa for European data sovereignty, that keeps sensitive values outside the platform they chose for compute and storage.
Last year we shared that we were building KMS and Secrets Manager for Thalassa Cloud. Today we are happy to be opening our Key Management Service (KMS) in Early Access.
What is KMS, and why does it matter? A Key Management Service (KMS) is where you create, store, and control the cryptographic keys used across your environment. Applications and platform services call the KMS API to encrypt data, verify signatures, or generate keyed hashes — instead of embedding key material in configuration files or managing crypto libraries per service.