Differences to APPUiO Public

APPUiO Cloud is the successor to APPUiO Public. This page lists the most notable differences.

This is only a summary for convenience and may not be complete. For the exact set of features, see the APPUiO Cloud Product Documentation. In case of differences, the APPUiO Cloud Product Documentation takes precedence.


Billing Model

In APPUiO Public, the Quota applied to a namespace was billed. For APPUiO Cloud we changed that completely, you only pay for what you use (metered billing).

Support Model

With APPUiO Cloud we’ve well-defined Support Packages available. Community support is included by default, whereas additional support by VSHN can be ordered in addition.

Changes to Backups

Persistent storage in APPUiO Public was provided via GlusterFS, which was also being backed up automatically by the underlying system. Users that needed to restore data could request a data restore via support. In APPUiO Cloud persistent volumes aren’t automatically stored in backup. For having backups of persistent volumes we offer the latest version of K8up on the APPUiO Zones.


Based on OpenShift 4

APPUiO Public was based on OpenShift 3.11, which was Kubernetes 1.11 under the hood. APPUiO Cloud is based on OpenShift 4 which brings a very recent Kubernetes version. The OpenShift upstream documentation discusses the differences in more detail.

Login via Keycloak and Two-Factor Authentication

Login is now handled via Keycloak which allows for Two-Factor authentication and identity brokering. It features single-sign-on throughout the whole platform. In APPUiO Public login was based on LDAP and didn’t allow for more secure login methods as well as no identity brokering.

Project / Namespace creation via Kubernetes API

In APPUiO Public OpenShift projects had to be created via the VSHN Portal. For APPUiO Cloud we changed that so that OpenShift projects and Kubernetes namespaces can be directly created via the Kubernetes API or via the OpenShift Webconsole. The is no need anymore to use a third part API or portal for that task.

Just use oc new-project or kubectl create namespace.

No Docker builds

APPUiO Cloud doesn’t allow Docker builds for security reasons, as the build process still relies on elevated privileges. APPUiO Public featured a self-made build tool called Aedifex which spun-up new virtual machines for image builds. This was an error-prone process and caused a lot of operational overhead. In APPUiO Cloud we recommend building container images outside the platform and either get the image from a public registry or push the image to the integrated registry. We recommend using GitLab CI/CD or GitHub Actions for automated image building. We closely monitor the possibilities of OpenShift. As soon as image builds are unprivileged we’ll revisit this feature and might allow image builds on the platform again.

Let’s Encrypt certificates only via Ingress object

TLS certificates can only be requested by using the standard Kubernetes Ingress object. This is due to the fact that we’re using cert-manager on the platform for managing Let’s Encrypt certificates. Unfortunately cert-manager doesn’t support the OpenShift Route object and doesn’t plan to do so in the future.

Check our how-to on generating certificates to get a closer look at how the new cert-manager based setup works.

No Dedicated Nodes

We currently don’t offer dedicated nodes on APPUiO Cloud anymore. The main reason for the dedicated nodes feature of APPUiO Public was cost, this is no longer a valid reason with APPUiO Cloud as the costs are much lower. Another reason was security, which only held partially true, as the control-plane was still shared between all users of the platform.

E-Mail sending via API

For sending E-Mails we recommend using a specialized E-Mail provider like mailgun. There is no SMTP Gateway available anymore.

Storage via IaaS CSI and Rook / Ceph

Persistent storage is provided by what the infrastructure offers via CSI integration and with Rook. In APPUiO Public, storage was provided via GlusterFS. Because of this change, the "Access Mode" for the Persistent Volume now actually matters, RWO provisions a "block storage" with a file system on it, RWX provides a shared file system (CephFS). See the Kubernetes upstream documentation which explains the storage topic in detail.

Networking with Cilium

We use Isovalent Cilium Enterprise for networking in APPUiO Cloud. In APPUiO Public the OpenShift 3 ovs-multitenant plug-in was used which for example didn’t allow Network Policies.

Different Quotas

In APPUiO Public each project had a Quota assigned, which could be changed by the user. For APPUiO Cloud there is a generic Quota applied to all projects which protects the platform from resource abuse. It should allow for most of the normal workloads. Should it not be enough for you, please request a quota increase via APPUiO Cloud support.

Default value for activeDeadlineSeconds for "run-once" pods

In APPUiO Public, the control plane restricted the execution time of "run-once" pods to 30 minutes by default. "Run-once" pods are pods that have a restartPolicy of Never or OnFailure. This was implemented using OpenShift 3’s mechanism to limit run-once pod duration.

On APPUiO Cloud, we don’t specify a hard limit on the time such pods can be active. Instead, we only apply a limit of 30 minutes to run-once pods which don’t have activeDeadlineSeconds set already. See the quota reference docs for more details on the mechanism.

Latest K8up version

Thanks to the recent Kubernetes version we offer the latest available K8up version.

Timezone of Control Plane

APPUiO Cloud uses UTC as timezone on the control plane which affects for example CronJobs. In APPUiO Public the timezone was set to Europe/Zurich.

Limited availability of logs

APPUiO Cloud stores logs only for three days. It’s also not possible to change the log retention for individual namespaces.