How to Deploy an Astro Site in Nigeria with OneBit Deploy

Introduction

If you have built an Astro site and you are ready to put it online, you have probably run into the usual friction: foreign platforms that require a Visa or Mastercard billed in dollars, unpredictable exchange rates, and support teams in time zones that are never convenient. OneBit Deploy solves that directly — you pay in Naira, no foreign card is needed, and support is reachable through channels that actually make sense for a Nigerian business.

This tutorial walks you through every step from signing in to going live with a custom domain. OneBit Deploy runs Node.js services, Next.js apps, Python apps (early access) and static sites, so an Astro project fits in one of two ways: a static build goes online as a plain website, and an Astro site with server-side rendering runs as a Node.js app. You do not pick which; the console works it out when you add the project. Go and PHP buildpacks are not available yet, although a repository that ships its own Dockerfile still builds.

Prerequisites

Before you start, make sure you have:

An Astro project that builds successfully on your local machine. Run npm run build and confirm the dist/ folder is generated without errors.
The project pushed to a GitHub repository you own or have admin access to.
An account on OneBit Deploy. Registration is free.

That is it. You do not need Docker installed locally. You do not need to write a Dockerfile. The platform handles all of that for you.

Go to deploy.onebit.ng and sign in. You land on Apps at code.onebit.ng.
Press Add app. There is no type to pick: whether your Astro build is static or uses server-side rendering, the console works it out from the project.
Open the GitHub account tab and press Connect GitHub. OneBit Deploy installs its GitHub app on your account so it can read the repositories you select and receive push events.
On GitHub's permissions screen, choose Only select repositories and tick the repository that contains your Astro project. Avoid granting access to all repositories unless you intend to deploy several of them.
Confirm, and GitHub returns you to Add app with your repository available to select.

Scoping the app to a single repository keeps your other codebases isolated and is a good security habit regardless of the platform you use.

Step 2 — Pick the Repository and Let the Platform Detect Your Stack

Select your GitHub repository from the list.
Choose the branch you want to deploy under Branch — typically main or production — and press Import.
OneBit Deploy auto-detects the Astro stack and writes an optimised Dockerfile. The docs call this zero-config: you do not need to supply a Dockerfile, a nixpacks.toml, or any other build manifest. The platform reads your package.json, recognises Astro, and generates the correct build and serve instructions automatically.
Review what the console says it found, and the Name. If everything looks correct, press Deploy; the first build starts straight away.

If auto-detection picks the wrong entry point for some reason, you can override the kind of project and the build command under Build settings before you press Deploy, and the output directory later in the app's Settings → Build settings → Edit build settings.

Step 3 — Set Environment Variables and Secrets

Many Astro projects need environment variables — API keys, public site URLs, feature flags, and so on.

Open your app and go to its Environment tab.
Under Add variable, enter the Name (for example PUBLIC_API_URL) and its Value, then press Add. To bring a whole .env over, use Bulk add (.env).
Every value is masked in the console after you save; press Show when you need to see one again.
Saving restarts the app so it picks the value up.

Add all the variables your build needs at this stage. Missing environment variables are one of the most common reasons a first deploy fails; values your build reads (like PUBLIC_ ones) only take effect once the app is built again, which Step 4 covers.

Step 4 — Trigger the First Deploy

The initial build started when you pressed Deploy. If you added keys your build needs afterwards, press Redeploy at the top of the app page to build again with them.
The app page shows each step, and its Logs tab (under Build) shows a live build log. You will see the platform pulling your code, running npm install, executing npm run build, and packaging the output.
When the build completes, your site is live on a public URL with HTTPS already handled, so you can preview it immediately.

From this point forward, every push to the connected GitHub branch triggers an automatic build and deploy. You do not need to return to the console each time you ship a change. Commit, push, and the platform takes it from there.

Step 5 — Roll Back a Bad Deploy

Deployments go wrong. A dependency update breaks a component, or a configuration change has an unintended side effect. OneBit Deploy keeps a history of every build tied to the Git commit that produced it.

To roll back:

Open your app and go to its Deployments tab. Roll back puts the previous successful deployment back.
To go further back, look down the list on the same tab. Each entry shows the commit, its date and how it went.
Find the last known-good commit and press Rebuild on it.
The platform rebuilds from that specific commit and promotes it to live traffic.

You can deploy any specific previous commit — you are not limited to the single most recent rollback point. This means you can jump back several commits if a regression was introduced gradually over multiple pushes.

Step 6 — Attach a Custom Domain

A platform subdomain is fine for testing, but your users expect your own domain name.

Open your app and go to its Domains tab.
Under Add domain, enter your domain name, for example www.yourbrand.ng, and press Add.
OneBit Deploy shows you the DNS record to create — typically a CNAME for a subdomain. Copy the host name and target value shown in the panel. (A .ng name you bought from OneBit needs no records: open Domains, open the name and press Set target.)
Log in to your domain registrar — Qservers, Whogohost, Namecheap, or wherever you registered the domain — and add the CNAME record there. You update the DNS records at your own registrar; OneBit Deploy does not manage DNS at your external registrar on your behalf.
Save the record and allow time for DNS propagation. This can take anywhere from a few minutes to 48 hours depending on your registrar and TTL settings.
Once OneBit Deploy detects the record is resolving correctly, the name shows Secure · working: TLS is provisioned and renewed automatically. You do not need to install a certificate, configure Let's Encrypt manually, or set a renewal reminder.

For more detail on connecting a domain, the OneBit Domain help article covers registrar-specific instructions.

Alternative: Upload a ZIP Instead of Connecting GitHub

If your Astro site is fully static and you would rather not connect a GitHub repository — perhaps the project lives in a private local repository, or you are handing a finished build to a client — you can upload a ZIP file of your pre-built output instead.

This option is available for static sites only:

Run npm run build locally. Astro outputs the static files to dist/ by default.
Compress the contents of dist/ into a ZIP file.
In the OneBit Deploy console, press Add app on Apps and open the Upload .zip tab.
Drop the file there, check the Name and press Deploy. The platform serves the static files directly.

Note that this method does not give you automatic deploys on push — each update requires a new ZIP upload, with Upload a new .zip on the app's Deployments tab. For any project under active development, the GitHub integration in Steps 1 through 4 is the better workflow. Consult the OneBit Deploy support page if you run into issues with either approach.

Next Steps

Your Astro site is live, protected by TLS, and set up for continuous deployment. A few things worth doing from here:

Review the pricing page to understand the plan limits relevant to your traffic and build minutes.
If you are also running a Next.js project, the guide on deploying a Next.js app in Nigeria covers the same workflow with Next.js-specific notes.
Set up branch-based preview deployments if your workflow involves pull requests — deploy a staging branch to validate changes before merging to main.
Monitor your build logs after each push to catch dependency or configuration errors early.