Selected work
Infrastructure & application delivery

Hosting a marketplace on the client’s own infrastructure

Separate Test and Production clusters, PostgreSQL, OpenSearch and uploaded content, with reviewed releases and a recovery plan on client infrastructure.

  • Kubernetes
  • Helm
  • Backup & recovery

For a large marketplace project, I built the test and production environments on the client’s own infrastructure. The work covered the application and the services behind it, including the deployment process and preparations for recovering the environment if something went wrong.

The marketplace depends on PostgreSQL, OpenSearch and persistent storage for user-uploaded content. Getting it ready for production meant treating those dependencies as part of the application’s operation, alongside networking, domains and certificates.

Separate environments with a common deployment structure

Test and Production run on separate Kubernetes clusters. The team can deploy and check changes in Test before approving them for the live marketplace.

Helm defines the application deployment, with separate values for each environment. Both clusters use a common deployment structure, while the values files capture their configuration differences. This makes it easier to review what changes between environments and maintain the application as it develops.

The test cluster gives developers somewhere to work with the deployed application and its supporting services. It also gives the team an opportunity to catch configuration and integration problems before a production release.

A clear route from code to production

Self-hosted Gitea holds the source code and delivery workflows. Private runners execute the pipelines within the controlled infrastructure.

A push to the test branch starts the application build and deploys it to the test cluster. The team can then check the running version and make further changes through the same process.

Production follows a reviewed path from the test branch. Repository protection rules and review by the responsible maintainer govern which changes proceed. Approved code moves into the production branch, triggering the production build and deployment.

This connects the release decision to code that has already been available in Test. The team has a defined place to evaluate changes and a clear point at which someone takes responsibility for releasing them.

Preparing to recover the environment

The recovery plan covers the data the marketplace accumulates as people use it. PostgreSQL databases and uploaded content have encrypted off-site backups, with cluster and service configuration retained for rebuilding the environment.

Disaster recovery procedures account for those pieces together. Restoring the marketplace requires the application, its supporting services and its data to work together again. Networking, storage and certificates are part of that preparation too.

The client therefore has a hosting environment with a defined way to introduce changes and a plan for rebuilding it. Development can continue in Test while Production serves users, with releases and recovery treated as part of running the marketplace.

Working through something similar?

Tell me what you have and what you want to change.

Get in touch