Skip to content

Guide 6 of 7

Deploying Your App: Hosting and CI/CD

3 min read
Automated CI/CD Deployment PipelineCode is pushed from a local terminal to GitHub, which automatically builds, verifies, and deploys to Vercel or Zeabur.Local Terminalgit push originGitHub (CI)Continuous IntegrationAutomated build &test suite checksHosting & CDContinuous DeploymentVercel (goodsoil.cc)Zeabur (VPS Apps)

Building software locally is satisfying, but it becomes useful to others when they can open a URL and use it. Hosting platforms now automate much of the work that once required configuring a server by hand.

The right choice depends on what your application needs: a simple website, a server that stays running, a database, or a background task.

Here is what to know about hosting services, the choice between a managed platform and a virtual private server (VPS), and automated deployments.

What is CI/CD? (Explained for non-technical people)

Before looking at hosting providers, you may hear developers talk about CI/CD. It means using automated checks and deployment steps:

  • CI (Continuous Integration): A service checks a code change for problems such as build errors or failed tests.
  • CD (Continuous Deployment): After the checks pass, a hosting service builds and publishes the new version.

The exact timing depends on the project and provider. The useful idea is that a code change can move from your computer to the live site through a repeatable process.

GitHub as a deployment hub

GitHub is much more than a place to store backups of your code. It acts as the command center for modern software development:

  • It tracks every historical change you make, allowing you to roll back a mistake with a single command.
  • It integrates directly with hosting platforms like Vercel and Zeabur.
  • It provides free automated build runners (GitHub Actions) to execute tests automatically on every commit.

GitHub is widely used as the place where code history and deployment connections meet. Plans and limits vary, but the basic workflow is available to individual developers.

Choosing the right hosting: Serverless vs. VPS

Depending on how your application is built, you may use a managed hosting platform or a virtual private server (VPS). A managed platform handles more of the operating work for you. A VPS gives you more control but requires more setup and maintenance.

1. Vercel (Fast, Serverless Frontend Hosting)

Vercel is the platform currently hosting this exact website (goodsoil.cc).

Vercel is specifically optimized for modern frontend frameworks like Astro, Next.js, and static websites:

  • Zero-configuration deploys: You link your GitHub repository once, and every time you push code to main, Vercel builds and publishes your site automatically.
  • Global delivery: Pages can be cached and served from locations closer to visitors.
  • Automatic HTTPS: Custom domains can receive certificates that are renewed for you.

If your project is a content site, a front end, or a small service, a managed platform may be a reasonable place to begin.

2. Zeabur (VPS, Containers, and Full Backend Services)

If your application needs a database, a long-running connection, or background work, you need a service that can keep those parts running.

Zeabur is the platform I use for several other applications:

  • Container support: You can deploy services and databases using containers.
  • Networking: The platform provides ways to connect services and attach domains.
  • Less server maintenance: It handles more of the operating work than managing a VPS yourself.

The complete deployment workflow

Putting it all together, the modern software shipping routine looks like this:

  1. You write and test your application locally with a coding assistant or your usual development tools.
  2. You commit your clean changes and type git push origin main to upload the code to GitHub.
  3. GitHub triggers your hosting provider (Vercel for frontend sites, Zeabur for backend services).
  4. The provider compiles the code, verifies the build, attaches the custom domain, and routes traffic to the new version.

The time from push to a live site depends on the build and hosting provider. Treat deployment as a process to check, not a promise that every change appears immediately.