VPS Platform

As the number of projects and pipelines grew, local development started to break down in predictable ways. Heavy jobs blocked my machine for long stretches, fan noise became the soundtrack, and context switching became expensive because everything waited on a single laptop.

Worse, running heavy work locally introduced environment drift. Small differences in versions, paths, and machine state caused inconsistencies that only appeared late, usually when handing work off or trying to reproduce a build after time had passed.

The goal was straightforward. I wanted a stable runtime that could run long jobs reliably, keep deployments consistent, and act as a single place to execute pipelines the same way every time.

The need for a VPS was confirmed through repetition. The same failures happened often enough that it became clear this was not a one-off annoyance:

• Local heavy jobs slowed iteration. Running builds, exports, and processing jobs locally reduced throughput and made it harder to multitask.
• Reproducibility was fragile. A pipeline that worked on one day could fail a week later because the local environment had drifted.
• Handoffs became risky. When someone else needed to run the same pipeline or deploy the same artifact, the setup instructions became longer than the work.

This pointed to a clear solution: centralise the runtime, standardise execution, and make the operational steps easy to repeat.

I built a single VPS setup with a stable runtime and repeatable deployment steps. The intention was not to build a DevOps platform. It was to create a dependable place to run heavy work, with minimal moving parts and predictable behaviour.

• Stable runtime: a consistent environment for running pipelines so outputs do not depend on laptop state.
• Repeatable deploys: simple deployment patterns that reduce manual steps and avoid configuration drift.
• Runbook-first operations: a short set of steps for standup, deployment, and troubleshooting so the system remains usable over time.
• Separation of concerns: local machines for development and creative work, VPS for long-running or compute-heavy jobs.

The product decision here was to optimise for reliability and simplicity. A small system that works every week beats a complex system that only works when you are in the mood to maintain it.

• Everything local Simple to start, but it blocks work, increases iteration time, and makes reproducing results fragile.
• Managed platforms Convenient, but expensive for persistent compute and long-running pipelines. The cost curve grows quickly.
• Serverless-only Useful for short bursts, but a mismatch for long jobs, larger artifacts, and workflows that benefit from a stable runtime.

• A VPS configured for heavy jobs with predictable execution and stable dependencies
• Repeatable deploy steps that reduce manual configuration and drift
• A short operational runbook covering standup, deployment, and common troubleshooting paths
• A clear split of responsibilities so local work stays responsive while heavy jobs run elsewhere

• Job runtime (local vs VPS) Measures iteration speed. Faster and more stable runtimes reduce waiting, unblock multitasking, and make heavy pipelines usable as part of normal development.
• Failure rate Measures reliability and drift. A lower failure rate indicates the runtime is consistent and that the system is not dependent on laptop state.
• Time-to-deploy Measures operational friction. The goal is a short, repeatable deploy path that does not require remembering fragile steps.
• Monthly cost Measures sustainability. This validates that the always-on setup remains cheaper than managed alternatives for the workloads being run.

AI helped tighten the runbook, generate troubleshooting checklists, and identify likely causes when failures occurred. It was most useful for turning messy debugging notes into clean operational steps that I could reuse.

• Architecture diagram showing what runs locally versus on the VPS and how deploys flow
• Runbook excerpt as a portfolio artifact, demonstrating repeatable operations
• Inventory of workloads describing what pipelines run there and why they belong on the VPS
• Basic monitoring for uptime, disk, memory, and job failures so issues are caught early