Building startup infrastructure from the ground up

I’ve designed and built infrastructure for startups from the ground up, giving teams a place to develop, test and run their products. The work covers the full environment, from networking and storage to application delivery, access control and disaster recovery.

For the teams, this provides an environment they can use throughout a project: somewhere to prototype, review changes with a client and run the finished application.

Connecting development, testing and production

Kubernetes provides the foundation for hosting internal products, webshops and client websites. Smaller projects share a cluster, keeping maintenance manageable and giving new applications somewhere to run.

Within that cluster, Test and Production occupy separate namespaces. Network policies control communication between workloads, while resource requests and limits define the allocations for test applications. Development and production can share infrastructure with explicit boundaries around connectivity and resource use.

Helm packages the application deployments, with separate values for Test and Production. Both environments use the same deployment definition; configuration captures the differences between them. A new project can reuse this structure along with the common delivery pipeline.

The everyday workflow starts in self-hosted Gitea. A developer pushes a change to the test branch, triggering a private runner to build the application and deploy it to Test. The developer can check the running version, and the client can open a preview URL to try the changes.

Client feedback becomes part of the development cycle. The team can demonstrate a feature in the deployed application, adjust it and repeat the process before approving a production release.

Production releases follow review. Kubernetes rolling deployments keep applications available as new versions replace the old ones, with the rollout configured around that requirement. Domain configuration gives each application its address, and automated TLS certificate issuance and renewal maintain HTTPS across the environments.

Operating the environment beyond deployment

Company Google accounts provide a common identity for accessing services, including Kubernetes through Rancher. Tailscale connects team members to the private network over WireGuard, with access rules linked to those identities.

Network access and service permissions therefore follow the accounts the organisation already manages. Developers use their company identity to reach the tools and environments they need for their work.

Persistent data has its own recovery plan. Encrypted off-site backups cover PostgreSQL databases and user-uploaded content. Disaster recovery procedures also include cluster configuration and supporting services, accounting for the work required to rebuild the environment and restore its applications.

This gives the startups infrastructure they can keep using as new projects arrive. Another application can follow the existing deployment structure and delivery process, with access, certificates and backups already accounted for. The team has somewhere to develop the product, demonstrate it to clients and continue operating it after launch.