CI/CD Choices for a One-Person Cloud Consultancy

Both platforms give a generous free allowance for a single small project, which is usually enough for a solo consultant's own tooling. The calculation changes once you're running CI across several client repositories at once, each with its own test suite, since minutes across all of them count against the same account unless you're billing usage back to each client separately.

DevOps spend for a small technical services business tends to sit at a few percent of revenue when it's tracked at all¹, and for a solo consultancy that spend is almost entirely your own time, not a line item on an invoice. Keep pipelines simple enough that they don't quietly become a second job.

A solo consultant's engagements are often shorter than an agency's, which means your pipeline setup gets handed off sooner and more often. Favor whichever platform matches where the client's repository already lives rather than pushing your own preference, and keep your actual build logic in plain scripts the pipeline calls rather than deeply platform-specific configuration.

This makes a handoff a matter of explaining a short YAML file rather than untangling platform-specific features the client's next hire has never seen.

GitHub Actions requires less setup if the client is already on GitHub: workflow files are simple, and the marketplace of pre-built actions covers most common tasks without you writing custom scripts. GitLab CI takes slightly more setup time if you're new to its YAML structure, but its built-in container registry and merge request pipelines can save you from standing up a separate registry for a client who's containerizing their app for the first time.

Neither difference is large enough to justify learning a second platform from scratch for a single engagement. Go deep on whichever one you already know well.

The fastest way to protect your margin on a fixed-price engagement is a personal library of starter pipelines for the project shapes you see most often: a static site, a small API, a containerized service. Keep them generic enough that dropping one into a new client repository takes an hour of adjustment, not a rebuild.

Resist over-customizing a client's pipeline to show off platform features they'll never touch again. A client paying for infrastructure work wants a pipeline that runs reliably and that someone else could maintain later, not a showcase of everything the platform can do.

Keep your starter templates in version control themselves, treated as their own small project rather than a folder of files you copy by hand. When GitHub Actions or GitLab CI changes something about how a step behaves, you want to update your template once and know every future client project starts from the fixed version, not discover months later that half your clients are running a workflow file with a since-deprecated setting in it.

Most solo engagements need a simple pipeline and nothing more, but occasionally a client's needs genuinely justify more: multiple environments, a compliance requirement driving audit logging, or enough deploy frequency that self-hosted runners actually save real money over hosted minutes. Quote that work separately and explicitly, rather than absorbing it into a fixed price meant for a simpler setup.

A client who needs more than a basic pipeline usually also needs ongoing maintenance, which is a retainer conversation, not a one-time project. Recognizing the difference protects both your time and the client's expectations about what they're actually getting, and it also gives you a natural, honest reason to say no to scope that's crept well past what the original quote covered.

Say this plainly to the client rather than quietly absorbing the extra work: a bigger pipeline is a bigger ongoing commitment for both of you, and pretending otherwise just sets up a harder conversation a few months in.

Quote a larger CI/CD engagement separately when a client needs:

• Multiple environments, rather than one simple production deploy, each needing its own pipeline stage.
• A compliance requirement that drives audit logging, which goes beyond a simple pipeline and deserves its own line item.
• Enough deploy frequency that self-hosted runners save real money compared with hosted minutes.