Hosted CI Removal: Why We Still Ship the Site

Yes, we removed hosted CI and still ship the site because the deployment pipeline no longer depends on a hosted continuous integration service. Instead, we run tests and builds locally (or on a lightweight self-hosted runner) and push the artifact directly to the hosting provider, so the absence of hosted CI does not block releases. This article explains why that decision was made, how the new workflow operates, what risks it introduces, and how you can evaluate a similar approach for your own projects.

Why We Removed Hosted CI

Hosted CI services (like GitHub Actions, Travis CI, or CircleCI) run your tests and builds on their servers. They are convenient, but they come with costs: monthly fees for private repos, queue times during peak hours, and occasional outages that block your deployments. For a small static site with a short test suite, those drawbacks often outweigh the benefits.

Our project is a simple static site—HTML, CSS, a few JavaScript files, and a build step that minifies assets. The test suite runs in under a minute. We realized that we could run the same commands on a developer’s laptop or a small self-hosted server, and then upload the built files directly to our web host. That removed a dependency on a third-party service and cut our monthly bill to zero.

Another factor was control. With hosted CI, you are tied to the provider’s infrastructure. If they change their pricing, deprecate a feature, or suffer a security breach, your workflow is affected. By running the pipeline ourselves, we decide when and how to update tools, and we are not surprised by external changes.

How the New Workflow Works

The current deployment process is straightforward:

1. A developer pushes a commit to the main branch on the Git repository.
2. A local script (or a cron job on a small server) pulls the latest code.
3. The script runs the test suite (e.g., npm test or python -m pytest).
4. If tests pass, the script runs the build command (e.g., npm run build or make build).
5. The built files are synced to the web host using rsync or a similar tool.
6. A post-deploy check fetches the homepage and verifies the HTTP status code is 200.

This is essentially the same sequence a hosted CI would run, but it happens on hardware we control. The only manual step is triggering the script, which can be automated with a Git hook or a simple scheduler.

What We Gained and What We Gave Up

Removing hosted CI brought tangible benefits:

• Cost: No monthly fee for CI minutes. For a small team, this can save hundreds of dollars a year.
• Speed: No queue time. The pipeline starts immediately when we run it.
• Privacy: The code never leaves our machines, which matters if the repo contains proprietary logic or customer data.
• Simplicity: One less service to manage and one less set of credentials to rotate.

But we also lost some conveniences. Hosted CI provides a clean, isolated environment every time. On our local machines, a lingering dependency or a system update can break the build. We also lost the automatic parallel test execution that some hosted services offer—though for a small suite, that is not a real bottleneck.

The biggest trade-off is reliability. If the developer’s laptop is off, or the self-hosted server is down, deployments do not happen. We mitigate that by having a second machine that can run the script, and by keeping the build process documented so any team member can do it manually.

Common Problems and How to Avoid Them

Running CI yourself introduces a few pitfalls that are worth knowing about:

• Environment drift: The build works on one machine but fails on another because of different versions of Node, Python, or system libraries. Solution: use a container (Docker) to standardize the environment, or pin exact tool versions in a lockfile.
• Security: Your local machine may not have the same security patches as a hosted CI sandbox. If you handle secrets (like SSH keys), store them in a password manager or a dedicated secrets file that is not committed to the repo.
• No audit trail: Hosted CI logs every run. With local builds, you need to log output yourself. We append the build log to a file and keep it for a few weeks.
• Human error: A developer might forget to run the tests before deploying. We added a pre-push Git hook that runs the test suite automatically, so a commit is rejected if tests fail.

One misconception is that removing hosted CI means you stop doing continuous integration. That is false. CI is a practice—running tests on every change—not a specific tool. We still run tests on every push; we just do it on our own hardware.

Alternatives to Hosted CI

If you are considering dropping hosted CI, you have several options:

• Self-hosted runners: Some hosted CI providers let you run their software on your own machine. For example, GitHub Actions allows self-hosted runners, so you keep the same configuration syntax but execute jobs locally.
• Local scripts: As described above, a simple shell script that runs tests and deploys. This works best for small projects with a single maintainer.
• Build servers: A dedicated machine (even a Raspberry Pi) that runs a cron job. This is more reliable than a laptop because it is always on.
• Serverless functions: You could trigger a cloud function (like AWS Lambda) that runs your build. This is still a third-party service, but it is event-driven and you only pay per invocation.

Each approach has its own trade-offs. Self-hosted runners give you the best of both worlds: the convenience of a CI provider’s interface with your own hardware. Local scripts are the simplest but require discipline. Build servers are a middle ground.

How to Decide for Your Project

Before you remove hosted CI, ask yourself these questions:

• How long does your test suite take? If it is more than 10 minutes, local machines may be impractical.
• How often do you deploy? Daily deployments need a reliable, always-on runner; weekly deployments can tolerate a laptop.
• Do you have a team member who can maintain the local setup? If everyone is busy, the overhead may not be worth it.
• Are you subject to compliance requirements that demand audit logs? Hosted CI provides those by default; you would need to build your own.

For a small static site like ours, the answer was clearly yes. For a large application with hundreds of tests and multiple environments, hosted CI is likely the better choice. The key is to match the tool to the project’s size and complexity.

Frequently Asked Questions

Is it safe to deploy without hosted CI?

Yes, as long as you have a reliable way to run tests and build the site. The risk is not the absence of a third-party service; it is the absence of a consistent, repeatable process. If you document the steps and automate them with a script, you can achieve the same safety as hosted CI.

Do we still get a preview of the site before publishing?

Yes. We build the site locally and serve it on a local port (e.g., localhost:8000) to review changes before pushing to production. For a more formal preview, you could deploy to a staging subdomain manually, but we find that local review is sufficient for our static site.

What happens if a test fails during a local build?

The script exits with a non-zero code, and the deployment step is skipped. The developer sees the error in the terminal and must fix it before the script will proceed. We also have a Git hook that prevents the commit from being pushed if tests fail, so a broken state rarely reaches the main branch.

Can we still collaborate with other developers?

Absolutely. The Git workflow is unchanged: everyone pushes to the same repository. The only difference is that the build and test step runs on a developer’s machine instead of a cloud server. As long as the build process is documented and the environment is reproducible (e.g., using a Dockerfile), any team member can run it.

Is this approach cheaper than hosted CI?

For a small project, yes. Hosted CI often charges per minute or per user, and free tiers have limited minutes. Running the build on your own hardware costs only electricity and time. However, if you factor in the time spent maintaining the local setup, the savings may be smaller than they appear. For a team of one or two, it is usually worth it.

What if we later want to move back to hosted CI?

That is easy. The build and test commands are the same; you would just move them into a hosted CI configuration file. The key is to keep your build process independent of the runner. As long as you use standard commands (like npm test or make build), you can switch back without rewriting anything.

Related

• Does iCloud Backup Voice Memos? Yes, Here’s How
• SQLite3 Command Line: Usage & Examples
• Crash-Proof Optical Disk Backups: A Practical Guide