Cloud-oriented delivery

Cloud as a way to run the platform

We deliver applications so they can run in a Kubernetes cluster on Google Cloud, AWS, or Azure. The point is a platform that can be scaled when the traffic is real, and understood when it is not. A cluster diagram is not the deliverable. A deployment you can repeat, a cost you can see, and a failure you can diagnose are.

Drupal and the services beside it are packaged to run there: containers, configuration, and a clear place for files, cache, and the database. The provider follows the estate you already have or the procurement you are allowed to use. We do not move a platform to a second cloud for the aesthetic of being cloud-first.

Sized, then handed over

Global scalability is a property you turn on when the audience is global. For a programme site, the more common need is a boring, available deployment in the region your users and your data rules require. We size for that, and we write down what would have to change if the audience grows.

Handover includes the manifests, the pipeline that applies them, and the accounts your team will use. A cluster that only we can enter is not a delivery. After the first production release we stay long enough to watch a real deploy, then the platform is yours to operate.

• Kubernetes on Google Cloud, AWS, or Azure, matched to the estate you can procure.
• Drupal and related services packaged as containers with configuration outside the image.
• A deployment path from GitLab to the cluster, reviewed like any other change.
• Notes on cost, region, and what your own team does when a pod fails.

The question to bring

Bring the provider you are allowed to use, where the data may live, and what "available" means on a Tuesday morning. We reply within 24 hours. If the honest architecture is a single well-run server for now, we will say that too.

This work sits inside Cloud & AI Development. Request information — tell us the organisation, the platform, and the constraint.