AppCat Update – StackGres End of Life Announcement
10. Jun 2026
AppCat v4.188.0 is a smaller release focused on technical improvements under the hood – but it brings one important announcement for you: VSHN PostgreSQL with StackGres is reaching End of Life on 31 August 2026.
VSHN PostgreSQL with StackGres – End of Life as of 31 August 2026
VSHN PostgreSQL with StackGres will reach End of Life on 31 August 2026. All new PostgreSQL instances already use CloudNativePG – which became the default in the previous AppCat release. If you haven’t migrated yet, now is the time.
You have two options:
Migrate your existing instances yourself by following the migration guide.
The bigger picture: a maturing sovereign ecosystem
The move away from StackGres is part of the broader evolution of AppCat as the operational foundation of VSHN’s sovereign managed-services ecosystem.
If you want to understand where AppCat fits in the larger picture – from Framework 0.1 back in 2021 all the way to Servala and AppSlap 2.0 today – read our recent post: A guided tour through our digitally sovereign ecosystem.
Continuous improvements behind the scenes
As with most AppCat releases, v4.188.0 also includes a number of smaller technical improvements that keep the platform stable and maintainable. These are the kinds of changes that don’t make headlines but are exactly what keeps production workloads running reliably over time.
A guided tour through our digitally sovereign ecosystem – Liene at KCD Czech & Slovak 2026
8. Jun 2026
At KCD Czech & Slovak 2026 in Prague, I took the stage to walk the audience through five years of building a digitally sovereign managed-services ecosystem from the ground up – the architectures that worked, the ones we threw away, and the bigger picture of where this is all going. The conference ran on May 21-22 at the Faculty of Information Technology, CTU in Prague, in three languages and packed with the wider European cloud-native community.
True to form, I framed the whole talk around Czech food – each chapter of the journey paired with a dish.
Watch the recording of my talk
The starting point: a single customer project
The story starts in February 2021 with what looked like a normal customer project. The ingredients: Crossplane v0.17, MariaDB, Redis, and an external Cloud Foundry that needed databases on demand via the Open Service Broker API. We called this Framework 0.1.
The architecture was already recognisably what we’d build on later – a control-plane cluster running Crossplane with XRDs and Compositions, talking to one or more service clusters through provider-helm, provider-sql, and provider-kubernetes. Customers ordered an instance, Crossplane composed it, and the right Helm releases, database objects, users, and Kubernetes resources showed up in the service cluster. Four environments: dev, nonprod, prod-nonpremium, prod-premium.
That worked. So I asked the obvious next question: if it works for one customer, can it be a product?
AppCat 1.0: from project to platform
By December 2022 we had AppCat 1.0 – VSHN’s Application Catalog – first wired up to external services, then by 2025 with our own catalog of managed PostgreSQL, Redis, MariaDB, Keycloak, and MinIO. The framework had matured into what we now call Framework 1.0: a clean stack with Service Definitions (XRDs), Service Implementations (Compositions), Crossplane as the control plane, and provider plugins for $App, $Cloud, and Helm – all driven by the Kubernetes API and exposed through the OSB API.
This is the picture most people see when we talk about Crossplane at VSHN. We’ve been running it in production since 2021, we’re an official Crossplane vendor, and we’ll happily argue that you should stop fighting Terraform state and manage your infrastructure through Kubernetes instead. But the framework diagram on a slide hides everything that makes a managed service actually managed.
The unglamorous middle: everything that makes a service managed
The “more features” slide was deliberately boring – a wall of words that anyone who has run a managed database in anger will recognise: backup, restore, logs, metrics, alerting, maintenance, version upgrade, scaling, user management. Plus application-specific things like Collabora for NextCloud, plus giving customers a free choice of infrastructure underneath.
This is where the real engineering lives. The control plane is the easy part. The hard part is everything you have to build, automate, and operate around it before a customer can rely on it at 3am on a Sunday.
The detour: split architecture (and back again)
Not every decision survives contact with reality, and I was refreshingly direct about one we walked back. At some point we tried a Split Architecture – separating the control cluster from the service cluster more strictly, with Crossplane on one side, managed resources and providers in their own namespace, and instances deployed into a service cluster on the other side. The diagram was elegant. The operational reality was not.
So we went back to one cluster. The “Nope – back to one cluster” slide – with the instance namespace dramatically circled in red – got a laugh, and it makes a serious point: sovereignty and operational simplicity aren’t opposed. Sometimes the right answer is the boring one.
Crossplane v2.0 – deliberate adoption
By August 2025 Crossplane v2.0 was on the horizon, with significant changes to how Compositions and packages work. Our position was simple: we wait. Not because we’re conservative for the sake of it, but because the framework we’d built was carrying real production workloads and the migration needed to be deliberate, not opportunistic.
In the meantime, we kept going.
Framework 2.0 and AppSlap
By May 2026 we had Framework 2.0, with a much cleaner separation between what service maintainers do and what framework engineers do. Service maintainers work with a ServiceBundle that references their custom functions. A Converter turns that into proper Crossplane artifacts – Composition, Composite, package metadata – using the VSHN function stdlib. The Crossplane CLI reads those artifacts and builds the Crossplane package. The whole pipeline is what we now call AppSlap 2.0.
The point of this isn’t the diagram. The point is that we can now onboard new services without rebuilding the framework around them – which is what you need if you want an ecosystem rather than a product.
Servala – the sovereign app store
May 2026 also marked the Codey instance running in production on Servala – the part of all this that turns a framework into an ecosystem. Servala is, in plain terms, a sovereign app store: a marketplace and ecosystem hub that connects four kinds of players and routes services to customers.
Cloud Service Providers bring sovereign infrastructure – compute, storage, network
Software Vendors bring the applications and tools, open source and commercial
Managed Service Providers bring 24/7 operations and support
Implementation Partners bring consulting and integration
Servala sits in the middle. Customers get sovereign managed applications without having to assemble the network themselves, and without locking themselves to any single party in it.
This is what I mean when I say sovereignty is a network problem, not a software problem. No single vendor can credibly claim to be sovereign end to end. What you can do is build the connective tissue that lets independently sovereign providers compose into something a customer can actually buy and run.
What it takes from a sovereign cloud provider
A practical note from the talk: not every cloud calls itself sovereign, and not every sovereign cloud is ready to host this kind of stack. I listed the concrete requirements: a real API to manage cloud resources, self-service VM provisioning, custom VM base image upload, S3-compatible object storage, fast SSD block storage, CSI storage attachments at scale (100+), a managed load balancer with 100+ listeners, NAT gateway and firewall. If any of these are missing, the ecosystem doesn’t land.
These are not exotic asks. They’re the baseline that hyperscalers normalised a decade ago. The good news is that a growing number of European and Swiss providers now check all the boxes – which is what makes the whole project realistic in 2026 in a way it wouldn’t have been five years ago.
Always under construction
One of the slides was just a picture of the Sagrada Família. I took the joke – and the seriousness behind it. Building a sovereign ecosystem is a long game. There’s no version where you finish, take a photo, and walk away. The framework will keep evolving, Crossplane will keep evolving, partners will join and leave, and customers will ask for things nobody has thought of yet.
The CNCF landscape slide made the same point a different way – the cloud-native ecosystem is enormous, and standing on its shoulders is the only sane way to build something at this scale. Sovereignty doesn’t mean reinventing everything. It means assembling the right things, with the right partners, in the right jurisdictions, and keeping the option to change your mind.
Conclusion
Five years in, one lesson stands out above all others: digital sovereignty is not a product that any single company can sell. It’s an ecosystem that has to be built together.
Thank you, Prague
Huge thanks to the KCD Czech & Slovak organisers and the local cloud-native community for two excellent days at FIT ČVUT. The conversations after the talk were as valuable as the talk itself – it’s clear that many people across Europe are thinking hard about what a sovereign, open, and operationally serious cloud-native ecosystem should look like.
I was genuinely energised by the discussions, questions, and feedback after the session. It’s encouraging to see how much interest there is in practical approaches to digital sovereignty and how many organisations are tackling similar challenges.
If you’re building sovereign cloud platforms, managed services, or ecosystem partnerships, I’d love to exchange experiences and explore how we can work together.
VSHN Application Catalog (AppCat) is VSHN’s platform for delivering production-ready managed services across multiple cloud providers and Kubernetes environments. Built on Crossplane and Kubernetes, AppCat automates the full lifecycle of services such as PostgreSQL, MariaDB, Redis, and Keycloak – from provisioning and upgrades to backups, monitoring, and day-2 operations.
What started as a solution for a single customer project has evolved into a framework that powers managed services for organisations across Switzerland and beyond. AppCat enables customers to consume services through self-service interfaces while giving operators a consistent way to manage applications across different infrastructures.
Today, AppCat serves as a core building block of the wider sovereign ecosystem presented in Liene’s talk. It provides the automation and operational foundation that allows managed service providers, cloud providers, software vendors, and implementation partners to collaborate through platforms such as Servala while maintaining openness, portability, and customer choice.
Liene Luksika
Product Manager
Latest news
General
Open Source
Press
Sovereignty
Sovereign Public Health Infrastructure: The Public Health Authority of Frankfurt Becomes a Global Red Hat Success Story
VSHN AppCat Update – CloudNativePG Becomes the New Default PostgreSQL
28. May 2026
The latest VSHN AppCat release v4.187.0 continues the platform’s transition toward a more Kubernetes-native PostgreSQL experience.
With this release, CloudNativePG officially becomes the default PostgreSQL implementation for all newly created PostgreSQL instances in AppCat. Existing instances remain unchanged, but new deployments will automatically use the CloudNativePG-based setup going forward.
This marks another important milestone in the maturation of PostgreSQL operations within AppCat.
CloudNativePG Now Default for PostgreSQL
CloudNativePG has steadily evolved within AppCat over the past releases and has now reached the point where it becomes the standard choice for new PostgreSQL deployments.
For users, this means:
New PostgreSQL instances automatically use CloudNativePG
Improved Kubernetes-native operations
Better long-term maintainability
Continued investment into the CloudNativePG ecosystem
Teams already running older PostgreSQL implementations can continue operating them normally, while migration planning can happen on their own timeline.
Improvements Across the Platform
Besides the PostgreSQL transition, the release also contains several operational improvements and fixes across the platform.
Better Garage CRD Version Handling
The release improves how Garage CRD versions are handled internally. This helps ensure more predictable behavior during upgrades and platform maintenance.
Improved topologyKey Handling for CloudNativePG
Topology handling for CloudNativePG deployments has been refined to improve scheduling consistency in Kubernetes clusters.
Better Warnings for enableSSHInRelease
The enableSSHInRelease handling now provides improved warning behavior, helping users better understand potential implications during deployments and maintenance operations.
Continuous Improvements Behind the Scenes
Many AppCat releases focus on operational excellence rather than flashy user-facing features – and that’s exactly what keeps production platforms reliable over time.
By making CloudNativePG the default PostgreSQL foundation and continuously refining platform behavior, AppCat keeps moving toward a more stable, Kubernetes-native and future-proof application platform.
VSHN AppCat Update – CloudNativePG PostgreSQL Reaches Full Maturity
28. Apr 2026
With AppCat v4.185.0, PostgreSQL based on CloudNativePG reaches full maturity. What started as a new foundation for running PostgreSQL on Kubernetes is now feature complete within AppCat.
A key step towards this milestone was closing the last remaining gap: self service restore.
Self Service Restore Completes the Feature Set
Self service restore for PostgreSQL was the final missing piece. With this feature now available, the CloudNativePG-based PostgreSQL service in AppCat is fully matured.
You can now restore your PostgreSQL instances yourself and test the process using the provided restore guide.
As part of this release, CloudNativePG PostgreSQL becomes the default database for new Nextcloud deployments.
This change only applies to newly provisioned instances. Existing setups remain unchanged.
When creating a new Nextcloud instance, it is still possible to connect to an already existing PostgreSQL database. For teams considering a migration, support is available when needed.
The release also addresses a practical issue in object storage handling.
Previously, buckets marked for deletion were not removed if they still contained data. As a result, these buckets continued consuming disk space.
With the introduction of garage cleanup, all objects within a bucket are deleted automatically once the bucket enters the deleting state. This allows the bucket to be removed properly and avoids leftover storage usage.
Summary
With self service restore now available, PostgreSQL with CloudNativePG in AppCat reaches full maturity. At the same time, it becomes the default choice for new Nextcloud deployments, while improvements like automatic bucket cleanup help address operational edge cases.
VSHN AppCat Update – Major PostgreSQL Upgrades and More Control over Costs
16. Apr 2026
Operating stateful services on Kubernetes has always been one of the more complex challenges – especially when it comes to databases like PostgreSQL.
With the latest VSHN AppCat release, we’re introducing a major milestone for our PostgreSQL offering based on CloudNativePG, along with improvements that give users more control over how their services are managed and operated.
This release focuses on three key areas: database lifecycle management, user control and cost optimization.
What is VSHN AppCat?
VSHN AppCat is the VSHN Application Catalog – a curated collection of production-ready applications that can be deployed and operated on Kubernetes with minimal effort.
Instead of manually installing and maintaining complex software stacks, AppCat allows teams to run services such as databases, identity providers or collaboration platforms as fully managed applications.
AppCat includes:
Automated operations and lifecycle management
Built-in monitoring, backup and maintenance
Consistent deployments across Kubernetes environments
This enables teams to focus on their applications, while VSHN handles the operational complexity behind the scenes.
Major PostgreSQL Version Upgrades with CloudNativePG
This release introduces a significant new capability for PostgreSQL in AppCat: major version upgrades using CloudNativePG.
For the first time, users can upgrade the major version of their PostgreSQL instances within the AppCat environment.
Major version upgrades are one of the more sensitive operations in database lifecycle management. Making this available as part of a managed service is an important step in enabling long-term, sustainable operations of PostgreSQL workloads on Kubernetes.
We’ve also introduced user management capabilities for PostgreSQL in our CloudNativePG-based offering.
While PostgreSQL itself has always supported user management, this functionality is now available and integrated within the AppCat-managed CloudNativePG setup.
This gives users more direct control over database access and roles within their managed PostgreSQL instances.
Operating databases and stateful services on Kubernetes is continuously evolving – and this release represents an important step forward.
With major version upgrades, integrated user management, and more control over backup infrastructure, AppCat continues to expand the capabilities of managed services on Kubernetes.
As always, the goal remains the same: making complex operations simpler, safer and more predictable for teams running production workloads.
VSHN AppCat Update – Enhancing PostgreSQL Flexibility and Platform Safety
13. Apr 2026
Running applications on Kubernetes is not just about deploying them – it’s about operating them reliably over time. That includes managing databases, handling authentication, and ensuring that services evolve safely without breaking changes.
With the latest VSHN AppCat release, we’re introducing improvements that focus on database flexibility, better integration capabilities and safer operations across the platform.
As always, many of these enhancements happen behind the scenes – but they directly improve how teams work with and operate their services.
What is VSHN AppCat?
VSHN AppCat is the VSHN Application Catalog – a curated collection of production-ready applications that can be deployed and operated on Kubernetes with minimal effort.
Instead of manually installing and maintaining complex software stacks, AppCat enables teams to run services like databases, identity providers or collaboration platforms as fully managed applications.
This includes:
Automated operations and lifecycle management
Built-in monitoring, backup and maintenance
Consistent deployments across Kubernetes environments
This allows teams to focus on their applications, while VSHN takes care of operating the underlying services.
One of the key improvements in this release focuses on PostgreSQL powered by CloudNativePG.
We’ve introduced additional configuration options for PostgreSQL extensions, allowing users to enable and configure extension-specific libraries where required. This provides greater flexibility for teams that rely on advanced PostgreSQL features.
In addition, support for VACUUM operations has been improved and is now more clearly integrated into scheduled maintenance processes. Regular VACUUM operations are essential for maintaining database performance and storage efficiency over time.
Together, these improvements give users more control over how their PostgreSQL instances behave – without sacrificing the benefits of a managed service.
Improved Integration with Forgejo
This release also enhances integration capabilities for developer platforms.
We’ve added support for configuring OAuth2 clients in Forgejo, making it easier to integrate Forgejo-based services with external identity providers and authentication systems.
This is particularly useful for teams that want to connect their development workflows with centralized identity management solutions.
Safer Operations for Nextcloud
Operating applications reliably also means preventing unsafe configurations.
With this release, we’ve introduced a safeguard for Nextcloud: major version downgrades are now explicitly blocked.
Since Nextcloud itself does not support downgrades between major versions, allowing them at the platform level could lead to broken instances or data inconsistencies. By enforcing this constraint, AppCat helps ensure that upgrades remain safe and predictable.
For users, the guidance is simple: stay up to date and follow the supported upgrade paths when moving between major versions.
Operating applications on Kubernetes is an ongoing process of refinement.
This AppCat release focuses on increasing flexibility where it matters – and enforcing safety where it’s critical. From more configurable PostgreSQL extensions to safer upgrade paths and improved integrations, these changes help teams operate their services with greater confidence.
As always, VSHN AppCat continues to evolve to make running production workloads on Kubernetes simpler, more reliable and more consistent.
VSHN AppCat Update – Improving Reliability, Operations and Developer Platforms
16. Mar 2026
Operating modern applications on Kubernetes is powerful – but it also comes with complexity. Databases, identity services, collaboration platforms and developer tools all require careful lifecycle management, upgrades, monitoring and security configuration.
That’s exactly where VSHN AppCat comes in.
With the latest release of AppCat, we’re introducing several improvements that further strengthen the reliability and operational consistency of the applications running on the platform.
While many of the changes happen behind the scenes, they directly improve the day-to-day experience of teams running production workloads on Kubernetes.
What is VSHN AppCat?
VSHN AppCat is the VSHN Application Catalog – a curated collection of production-ready applications that can be deployed and operated on Kubernetes with minimal effort.
Instead of installing and maintaining complex software stacks manually, AppCat allows teams to deploy widely used services such as databases, identity providers, collaboration platforms or developer tools as fully managed applications.
AppCat provides:
Production-ready Kubernetes deployments
Automated operations and lifecycle management
Built-in monitoring, backup and maintenance processes
Consistent deployments across Kubernetes environments
This means platform teams and developers can focus on building and running their applications while VSHN takes care of the operational complexity behind the scenes.
Reliable operations require good alerting – but alerts should be actionable, not overwhelming.
In this release we improved end-user alerting behaviour, reducing alert noise while keeping important signals visible. For example, alerts for storage capacity issues previously triggered every minute. While technically correct, this behaviour often resulted in unnecessary alert noise.
The new configuration adjusts the interval to 15 minutes, reducing alert flapping while still giving users enough time to react to potential issues.
If you haven’t configured alerting for your AppCat instances yet, we strongly recommend enabling it.
Improving PostgreSQL Reliability
Several improvements in this release focus on making PostgreSQL operations more robust.
One issue could occur when multiple databases were created simultaneously. In rare situations this could lead to race conditions during user management. By adjusting the database bootstrap process and using a more suitable template database, this issue has now been resolved.
These kinds of improvements might be invisible to users – but they are essential for making platform operations reliable at scale.
CloudNativePG for Keycloak
We also improved the PostgreSQL backend used by the Keycloak identity service in AppCat.
New Keycloak instances will now use CloudNativePG, a Kubernetes-native PostgreSQL operator designed specifically for cloud-native environments.
Existing Keycloak installations remain unchanged and continue to operate normally. The new backend will automatically be used when new Keycloak instances are created.
This release also includes updates to Forgejo and Codey, ensuring that these services run on supported upstream versions.
What is Codey?
Codey is VSHN’s European code collaboration platform, built on the open-source Forgejo project.
Instead of operating their own Git platform, teams can run fully managed Forgejo instances operated by VSHN, including monitoring, backups and lifecycle management.
Codey provides features such as:
Git repository hosting
Pull requests and code reviews
CI/CD compatible with GitHub Actions workflows
Package and container registries
Integrated project management tools
Codey runs on European cloud infrastructure, including Switzerland, helping organizations maintain control over their development data while benefiting from a fully managed service.
The release also includes improvements to the security configuration of the Nextcloud cronjob.
Previously the job could run with incorrect user permissions in some Kubernetes environments. The new configuration ensures the job runs with the correct security context, improving compatibility across Kubernetes platforms such as vanilla Kubernetes and OpenShift.
For services that include PostgreSQL dependencies – such as Keycloak and Nextcloud – we fixed edge cases where maintenance windows could slightly deviate from the configured schedule.
Maintenance operations are now handled more consistently across dependent services.
Continuous Platform Improvements
Operating applications reliably on Kubernetes requires constant refinement of automation, observability and operational processes.
This AppCat release focuses on exactly that: improving reliability, consistency and operational experience across the platform.
While many improvements happen behind the scenes, they ultimately help teams run critical services more safely and with less operational overhead.
If you’re looking for a simpler way to run production-ready services on Kubernetes, VSHN AppCat provides a proven foundation.
