SiteGround Academy

GitHub deployment turns a push into a live update. You push to a chosen branch, a build runs on GitHub Actions or on your host, and the result replaces the version your visitors see. GitHub starts the process. Your host keeps the application running.

What actually happens when you push

Pressing push feels like the last step. With auto-deploy, it is the second step of a six-step pipeline:

1. Commit. You save a snapshot of your changes in your local Git repository.
2. Push. The commit travels to GitHub, and the branch there now points at it.
3. Trigger. GitHub announces that the branch changed, often through a webhook, and whatever is listening reacts.
4. Build. A fresh copy of the code is fetched, dependencies are installed, and the build command runs.
5. Deploy. The build output is moved to where the server runs it.
6. Live. The application restarts on the new version.

From step 3, there are two ways this can go, depending on who runs the build: a GitHub Actions workflow on GitHub’s machines, or your host itself.

From commit to build

A build turns the code you wrote into code a server can run. Your repository holds source files, such as TypeScript, JSX, and a package.json that names dependencies without containing them. The build fetches a clean copy of the commit, installs those dependencies, and runs the build command, which compiles and bundles everything into an output folder. The build runs on either a GitHub Actions runner or your host’s own server, depending on which model you use.

Because the build starts from exactly what is in the repository, “it works on my machine” stops working as an excuse. A file you never committed, or a package you installed globally and never declared, is simply not there.

From build to live

If GitHub ran the build, a workflow step copies the output to your server. If your host ran it, the output is already where it needs to be. Deployment puts the build output, called an artifact, where the server runs it, then restarts the application on the new code. The careful method prepares the new version alongside the running one and switches over only once it is complete, so visitors never see a mix of both. The careless method overwrites live files one at a time, which is what a manual FTP upload does. On SiteGround Node.js Projects, every deploy creates a brand-new build, and older builds stay on the account until you delete them.

Environments: Why staging and production are separate

An environment is a named destination for your code, such as staging or production, with its own settings and secrets. Production is what visitors use. Staging runs the same code against test data, with a test database and a sandbox payment key, so a broken checkout charges nobody.

On GitHub, an environment is also a gate. GitHub’s documentation lists four types of deployment protection rules: required reviewers who approve the job, a wait timer that delays it, limits on which branches and tags can deploy, and custom rules checked by an outside service. Environment secrets are released only to jobs that target that environment, and only after approval when reviewers are required. GitHub also records deployments per environment, so the repository shows which commit is live where. These rules apply to GitHub Actions workflows. If your host deploys through its own GitHub App, protection rules don’t gate that deploy, and staging is something the host provides, or doesn’t.

CI, CD, and the words nobody defines

CI/CD is the umbrella term for automating everything between a commit and a release. It covers three practices, and “CD” means two different things depending on who is talking.

Continuous integration vs. continuous delivery vs. continuous deployment

• Continuous integration (CI) merges changes into a shared branch often and runs an automated build and tests on every one, so a problem surfaces at the commit that caused it.
• Continuous delivery automatically prepares every change that passes for release, but a person decides when it goes to production.
• Continuous deployment removes that decision. Every change that passes goes live on its own.

A host that rebuilds on every push to a linked branch is doing continuous deployment, even if no tests run. Putting tests in front of it is what makes it CI/CD. For the rest of the vocabulary, from pipelines to runners, see our vibe coding glossary.

What GitHub Actions does, and what it doesn’t

GitHub Actions runs your deployment process. It does not host your application. That one distinction clears up most confusion about GitHub deployment.

You describe a workflow in a YAML file in your repository’s .github/workflows folder, name the event that starts it, such as a push to main, and list the steps. GitHub starts a runner, a temporary virtual machine, which checks out your code, installs, tests, builds, and, if you wrote a step for it, sends the result to a server. When the job finishes, GitHub discards the runner.

Nothing from the run stays running, so a GitHub Actions deployment always has two halves: the workflow GitHub runs and a destination you provide, whether a cloud platform, a virtual server, or a hosting account. If that destination can build the code itself after a push, you may not need a workflow at all. When you do, GitHub’s deployment documentation covers the syntax.

Deploying to your own server or host

Deploying from GitHub to a server means connecting a repository to the machine that runs the application, so each push becomes a new live version. The two common approaches differ in who does the build.

Connecting a repository to a web host

• GitHub Actions pushes to the server. The workflow builds on a runner, then copies the result to your server over SSH, using credentials stored as encrypted repository secrets. You maintain the workflow, the keys, and whatever keeps the app running.
• The host pulls from GitHub. You authorize the host’s GitHub App once, pick a repository and branch, and the host builds and deploys every push on its own machines. There is no workflow to maintain.

SiteGround Node.js Projects take the second route. On the GrowBig, GoGeek, and Cloud plans, you connect a repository through the SiteGround GitHub App when you create a Node.js project, and every push to the linked branch rebuilds and redeploys the app. The branch, Node.js version, build command, and environment variables are adjustable in Site Tools, and auto-deploy can be paused without disconnecting the repository. Whether a shared plan suits your app is a separate question, covered in does shared hosting support Node.js.

Why GitHub Pages isn’t the same thing

GitHub Pages is a static site hosting service. According to GitHub’s documentation, it publishes HTML, CSS, and JavaScript files from a repository and serves them as they are. There is no Node.js process, no database, and nowhere for an API route to run. A portfolio or a documentation site suits it. An Express server or anything with a user login does not.

GitHub’s usage limits also state that Pages is not intended as free hosting for an online business, an ecommerce site, or commercial SaaS, and as of October 2026 they cap published sites at 1 GB. 

When a deploy fails

Most failures fall into one of two categories, and each is fixed in a different place, so work out which one you have first.

Failed build vs. failed deploy

A failed build is the safer failure: on a platform that switches versions only after a successful build, the old version keeps serving. A failed deploy can take the site down if the platform switches before confirming the new version starts. Hosts that copy files into the live folder add a third case, the partial deploy, where an interrupted upload leaves old and new files mixed, and the fix is a full redeploy.

Reading a deployment log

A deployment log is the transcript of every command the build ran, in order. Read it from the bottom up to find where it stopped, then look for the first error above that point, because the final lines usually report the consequence rather than the cause. Lines starting with + or > mark the command being run, and an exit status of 0 means it succeeded.

Warnings are where beginners go wrong, and a SiteGround Node.js test deployment we ran in September 2026 shows why. Midway through the install, npm printed a deprecation notice that reads like a problem. The build carried on and finished with a status of completed:

+ [...] npm install [...]

npm warn deprecated recharts@2.15.4: 1.x and 2.x branches are no longer active. [...]

+ [...] npm run build [...]

> vite build

+ exit 0

Build info: {"status":"completed"}

On SiteGround Node.js Projects, every build is listed in Site Tools > Node.js > Logs with its author, branch, status, and commit, and a Failed tab isolates the broken ones. Open a build’s Actions menu and select View build log, as described in how to manage a Node.js project in Site Tools.

Rolling back

Rolling back means returning production to the last version that worked. With push-to-deploy, the reliable method is git revert: it creates a new commit that undoes the bad one, and pushing it runs a normal build that puts the previous code live again. Avoid resetting the branch and force-pushing, which erases the record of what happened. Remember that a rollback restores code, not data, so database changes the bad release made stay in place. 

On SiteGround Node.js Projects, older builds on the Logs page can be viewed or deleted but not reactivated, so reverting and pushing is how you roll back. 

Is auto-deploy worth it for a small project?

For most projects with a build step, yes. For a static page you touch twice a year, no, and a manual upload is fine.

Auto-deploy pays off when changes are frequent, when the project must be built before it runs, or when more than one person ships code. That includes most apps built with vibe coding tools, where push-to-deploy becomes the final step of the vibe coding workflow. The cost is up front: the project has to live in Git and on GitHub, and if your host does not build for you, you also need a workflow, SSH keys, and secrets. For someone new to Git, learning it is the real price, and it is worth paying anyway.

Putting GitHub deployment to work

GitHub deployment comes down to one chain: push, trigger, build, deploy, live. Once you can name each link, a failed build becomes a log to read rather than a mystery. If your next project is a Node.js app, SiteGround Web Hosting runs Node.js projects from the GrowBig plan upward with GitHub auto-deploy built in, so the host handles the build. If it is an API, hosting a Node.js API backend picks up from here, and if you are still deciding where any project should live, start with how to host a website. 

[86]

Frequently asked questions about GitHub deployment

An API backend needs less from a host than the market implies: a process that stays up, a database, secrets storage, a deploy path, and TLS. Most managed platforms can do all five.

A Node.js API backend is a long-running process that answers HTTP requests and returns JSON. It does not need a dedicated server, a container orchestrator, or a platform priced per instance. It needs somewhere that keeps the process alive, gives it a database and a domain, and redeploys it when the code changes. Node.js server hosting on a managed shared plan covers that, provided you know where the ceiling is.

What an API backend actually needs from a host

Strip away the marketing and an API backend has a short requirements list. Check your own service against it before you compare providers, because most of the differences between hosting products sit above this line, not below it.

• A process that stays up. Your API starts once and answers every request from memory. Something has to restart it when it exits.
• A database it can reach. Usually relational, usually on the same network, ideally not a separate subscription.
• Somewhere to put secrets. API keys and connection strings belong in the host’s environment settings, never committed alongside your code.
• A deploy path you will actually use. If shipping a change is tedious, you will ship fewer of them.
• TLS on a domain you control. Mobile clients will not talk to an untrusted certificate, and most will not talk to plain HTTP at all.
• Logs when a deploy fails. Build output you can read is the difference between a five-minute fix and an afternoon.

Notice what is missing. Horizontal autoscaling, container control, and a private network are real requirements for some services. However, for many early-stage mobile apps, those capabilities are headroom rather than baseline requirements, so paying for them before the workload demands them can add unnecessary cost and operational complexity.

What “API hosting” actually means

The phrase covers three different products, and search results mix them freely. Knowing which one you are being sold saves a lot of wasted evaluation time.

API hosting compared with API gateways and API management

API hosting is application hosting. The provider runs your code as a live process and routes traffic to it. This is what you need if you have written an Express, Fastify, NestJS, or Koa service and it has to exist somewhere.

An API gateway sits in front of an API that already exists. It handles routing, rate limiting, authentication, and request transformation. A gateway does not run your code, and buying one when you needed hosting leaves you with a very capable front door and nothing behind it.

API management is the commercial layer on top: developer portals, usage plans, billing, and analytics for APIs you expose to third parties. It matters when your API is the product. It is irrelevant when your API exists to serve your own front end.

For most teams shipping a mobile app or an internal tool, the answer is the first one, and the other two are problems for a later year.

Where an API backend can live

Four models can run a Node.js API. They differ less in capability than in how much of the operational work they hand back to you.

Application platforms

Platforms built specifically to run application code give you the most headroom: horizontal scaling, WebSocket support, container-level control, and regional deployment. They are the correct answer for a service with real concurrency demands or persistent connections. The trade is that pricing is metered, the database is usually a separate product, and a domain, mailboxes, and backups are yours to arrange. 

Managed shared hosting

A managed shared plan runs your Node.js application as a supervised process alongside the rest of your hosting account. You get a fixed monthly price, a database, a domain, and email in the same place. The control panel covers the deployment, and the familiar hosting tools sit underneath it: a file manager, scheduled jobs, and SSH access to your own account. What you do not get is a server to administer. For a request-response API that is mostly upside, because there is less to configure and less to leave misconfigured.

A VPS

A virtual private server gives you root, and with it every decision: the operating system, the process manager, the reverse proxy, the certificates, and the patching schedule. Choose it when you genuinely need that control. Choosing it by default means you have taken on a systems administration job in order to host a JSON endpoint.

Serverless functions

Functions suit spiky, short-lived work: webhook handlers, scheduled jobs, image processing. They suit a conventional REST API less well, because a persistent database connection, an ORM, and a per-invocation execution model fight each other. Many teams that start an API on functions migrate it to a long-running process within a year.

What it actually costs to host an API backend

The advertised price of an application platform is rarely the amount you pay. Work out the total before comparing, because the shape of the bill differs more than the headline figure.

What free tiers cost you in cold starts and sleep

Free and entry tiers on most application platforms suspend an idle process. The next request has to wait for it to start again, and that wait is measured in seconds rather than milliseconds. On a web page it reads as slow. On a mobile client with a timeout it reads as a failure, and your user sees an error rather than a spinner. This is the cost that never appears on a pricing page, and it is worth measuring on any host you are considering: deploy something, leave it alone for an hour, then time the first request yourself. 

What you pay for on a metered platform once the database is added 

Metered platforms bill the running instance, then bill separately for the parts an API needs anyway. A managed database is typically its own line item. A custom domain has to be bought elsewhere. Mailboxes on that domain are usually not offered at all. Egress and build minutes may be metered on top. None of this is hidden, but it is easy to compare an instance price against a hosting plan price and conclude the platform is cheaper. 

What a fixed-price plan covers

A shared hosting plan bundles the pieces. The database, the domain, email on that domain, TLS, daily backups, and a WAF come with the plan rather than alongside it, and the price does not move with traffic. For an API that serves a mobile app with a few thousand users, predictable beats elastic. The ceiling is real, but you reach it later than most people expect, and you reach it knowing exactly what the next tier costs.

When a shared plan is the wrong home for your API

This is the section most hosting comparisons skip. A managed shared plan is a poor choice for several kinds of API, and finding that out after migrating is expensive.

• Your API holds open connections. WebSockets are not supported on any SiteGround plan, because opening a custom port for incoming connections is not permitted. This applies across shared hosting, and we cover what shared plans can and cannot run in more detail separately. Long polling over HTTP and HTTPS is the documented alternative and is adequate for infrequent updates, not for a live feed. 
• You need to operate the live process. You get a build log for every deploy and an HTTP error log for traffic that reaches the app. What you do not get is a managed application log: your own console output is not surfaced in the panel. You can write it to a file and read that over SSH, but if you expect to tail a live process or attach a debugger, a VPS will suit you better.
• Your data store is not relational. MySQL and PostgreSQL are both available. A document store such as MongoDB means connecting to an external managed service and accepting the latency that adds.
• Your traffic is genuinely large or genuinely spiky. A shared plan is a fixed slice of a shared machine. An API under heavy sustained load wants dedicated resources, not a bigger shared allocation. 

Running a Node.js API backend on SiteGround

Which plan your API needs

The StartUp plan does not support Node.js, so availability begins on GrowBig. GrowBig runs up to 5 Node.js projects, GoGeek up to 10, and Cloud is unlimited. Count your projects before you pick a tier, and remember that a staging copy of your API counts as a project of its own. A team running one production API and one staging environment per client reaches the GrowBig limit at two or three clients, which is usually what moves an agency up rather than disk space.

Getting your API deployed

Connect a GitHub repository and every push to the linked branch rebuilds and redeploys the service, which is the path worth using for anything under active development. Uploading an archive works too but has no auto-deploy. The mechanics are the same for any Node.js application and are covered in our guide to Node.js support on shared hosting.

The part specific to an API is the environment settings. Database connection strings, third-party API keys, and signing secrets are configured against the project rather than committed to your repository, which also means a staging deployment can point at a different database without a code change.

The database, and pointing a client at it

MySQL and PostgreSQL are both created and managed from Site Tools. PostgreSQL is the one worth noting, because it is uncommon on shared plans and it means an API written against Postgres with Prisma, TypeORM, or Sequelize deploys without a rewrite or a separate database subscription. MongoDB is not available, so a document-store API connects to an external managed service.

Every project starts on a temporary domain, which is more useful for an API than it sounds. Your mobile or front-end client can point at that endpoint and exercise the real service while DNS for your own domain is still pointing somewhere else. Attach your domain when the client is ready, and the API keeps answering on a certificate you control.

Choose the hosting model your API actually needs 

If your API answers HTTP requests, you can live without WebSockets, and you would rather not be responsible for the server underneath it, SiteGround Web Hosting covers Node.js server hosting from GrowBig upward, with the database, domain, email on that domain, daily backups, and a WAF included rather than bought separately.

The right hosting choice is the simplest one that meets your API’s actual requirements without making you operate infrastructure you do not need.

Frequently asked questions

If you’re comparison-shopping after a GoDaddy renewal jump, add-on fees, or a website builder that hit its ceiling, these six alternatives cover beginners, online sellers, and agencies alike. SiteGround leads the list for combining hosting and a builder, backed by security and performance built in from day one, with the option to add ecommerce, email marketing, or AI-assisted building as your site grows.

Why people look for a GoDaddy alternative

If your renewal price jumped past what you signed up for, your store broke at checkout, or your website builder hit its ceiling, you might be looking for something else entirely.

SSL that isn’t free forever

GoDaddy’s Economy plan includes SSL (Secure Sockets Layer) free for the first year, then charges $119.99 a year after that, one of several ongoing hosting costs worth checking before you commit to a plan.

Most of the alternatives on this list, including SiteGround, include free SSL with no time limit, not just a first-year deal.

Support that’s hard to reach when something breaks

WebsitePlanet’s own testing of GoDaddy alternatives describes a slow, hard-to-reach support experience firsthand; WPBeginner built an entire piece around the same frustration. Support quality is the kind of thing you don’t notice until you need it, and by then it’s too late to shop around. SiteGround offers phone, chat, and ticket support 24/7, not every alternative on this list does, Hostinger, for instance, doesn’t offer phone support at all.

Hosting and a website builder, sold as one thing or two

Hosting and website building are often sold as separate products, adding friction when you’re trying to simplify your setup. Several of the alternatives below solve this directly, bundling a builder into the hosting plan itself rather than treating it as a second purchase.

How we picked these GoDaddy alternatives

Every option on this list met four criteria, the same ones worth applying whenever you’re choosing a web hosting partner:

1. Price transparency: is the renewal rate visible up front, not just the intro deal
2. What’s included by default versus sold as an add-on
3. Migration friction: how much work it takes to actually switch
4. Platform breadth: how much a switcher gets in one account

The best GoDaddy alternatives

Six options, each covered on its own merits.

SiteGround: The all-in-one platform pick

Best for: small businesses and growing websites that want more responsive support and a more integrated alternative to GoDaddy, with hosting, security, performance, and site-building included, plus ecommerce and marketing tools you can add as you grow.

Strengths:

• All-in-one platform: hosting and a website builder included, with ecommerce, email marketing, and AI tools available on the same account as your site grows, one login instead of juggling separate providers.
• Daily backups: 30-day history and one-click restore, included on every plan, so if something breaks or gets hacked, you’re not losing weeks of work, and you’re not paying extra for that safety net.
• Free SSL, for good: no renewal fee, included on every plan. GoDaddy’s SSL is free for one year, then $119.99/year after, here it’s free permanently.
• In-house WAF (Web Application Firewall), AI anti-bot protection: included by default, so your site is protected from day one, not just after you notice something’s wrong and go looking for a security add-on. Malware scanning (Site Scanner) is a separate purchase, worth adding if you’re managing client sites or a store.
• Multi-level caching stack: free on every plan, so your site loads fast without needing to buy your way onto a higher tier for it.
• Multiple ways to build your website: the website builder or WordPress, both free with hosting, so you’re not locked into one approach. For AI-generated sites, Coderick AI is available as a separate purchase, and ecommerce (the Sell plan) is a separate purchase too, once you’re ready to sell. Hostinger comes closest to matching this breadth, though its email marketing tool sits behind a higher plan tier.
• Migration performance: 80% of sites moved from GoDaddy to SiteGround load faster on the new host, with an average speed increase of 79.5%; the same pattern shows up moving from Hostinger (78% faster, 95% average increase) and Bluehost (84% faster, 75% average increase).

Trade-off: This breadth costs more than picking the cheapest bare-bones plan on this list, though the gap narrows once you factor in what several of those cheaper options charge extra for instead.

Bluehost

Best for: beginners who want a straightforward first website.

Strengths:

• WordPress.org’s long-standing recommendation: Bluehost has been an official recommended host for years, which means a well-worn path, with plenty of tutorials and community support if you get stuck.
• WonderSuite AI builder: a guided, AI-assisted setup that means you spend less time staring at a blank page deciding where to start.
• Included security: weekly backups, malware scanning, and automatic malware removal come standard on every plan. The web application firewall and DDoS protection, paired with AI-powered threat detection, are included from the Business tier up.

Trade-off: ecommerce (WonderCart) is gated to higher-tier plans, and there’s no dedicated email marketing tool if you outgrow a basic inbox.

Hostinger

Best for: switchers who want a similar mix of hosting, builder, ecommerce, and email marketing tools, at a lower entry price. Ecommerce is included from the entry plan; email marketing requires stepping up to the next tier. Email accounts on Hostinger’s entry plan are capped at 2 mailboxes, and its CDN isn’t included on the first tier either, both worth checking if you’re used to having more room to grow before hitting a wall.

Strengths:

• Horizons AI app builder: generates a working site from a prompt, a genuine alternative to a traditional builder if you want something built fast without learning WordPress first.
• Ecommerce and Hostinger Reach: built-in store tools and email marketing, the closest match to SiteGround’s all-in-one setup on this list.
• Free SSL and WAF included: security basics covered without an add-on.
• NVMe (Non-Volatile Memory Express) storage across plans: consistent performance regardless of tier.

Trade-off: email marketing requires stepping up a tier; the entry plan’s mailbox and CDN limits are also worth checking before committing.

DreamHost

Best for: reliability-focused switchers who want backups handled without thinking about it.

Strengths:

• Daily backups on every plan: no tier-gating, the one thing GoDaddy charges extra for, here included by default even on the cheapest plan.
• WAF and DDoS protection: included on every plan, confirmed directly from DreamHost’s own documentation.
• Liftoff AI builder: covers the basics of getting a site live without a steep learning curve.
• 25 sites on the entry plan: a real advantage for anyone managing more than one site under one account.

Trade-off: basic malware protection is included, but DreamShield, its more advanced scanning and alert system, is a paid upgrade, the same add-on pattern that pushes people away from GoDaddy in the first place.

HostGator

Best for: switchers who want a familiar, long-time GoDaddy rival with staging built in.

Strengths:

• Staging environments on every tier: normally a higher-tier feature elsewhere, included here even on entry plans.
• Cloudflare CDN (Content Delivery Network) with Argo Routing: included, not sold separately, for faster load times without an upgrade.
• Free SSL and DDoS protection: included as standard, alongside complimentary malware scanning on shared plans.

Trade-off: the entry plan only includes chat support, no phone line. If your site goes down during a busy sales weekend and typing out the problem feels too slow, getting someone on the phone means stepping up a tier first.

Namecheap

Best for: switchers whose main GoDaddy frustration was domain-related upsells rather than hosting performance.

Strengths:

• Low entry pricing: the cheapest way onto this list if budget is the deciding factor.
• Domain-first reputation: transparent registration pricing and management tools, with fewer surprise upsells at the exact point where GoDaddy’s pricing tends to frustrate people most.
• DDoS protection included: standard even at this price point.

Trade-off: no dedicated ecommerce product, so the cheapest plan on this list isn’t a fit if you’re planning to sell online.

How to move your site off GoDaddy

Migration breaks down into four pieces: DNS (Domain Name System), files, domain, and email, the same fundamentals as hosting a website from scratch.

1. Set up email on your new host first. Get it running and confirmed working before touching anything else, so your inbox never goes down mid-move.
2. Update your MX (Mail Exchange) records once the new email is verified, then keep GoDaddy’s email active in parallel until you’re sure everything’s landing correctly.
3. Copy your files and database. Most hosts, including SiteGround, offer a free migration plugin that handles this automatically, so it’s rarely a manual, file-by-file transfer.
4. Point your domain at the new host’s nameservers. DNS propagation is usually a matter of hours, though it can occasionally take up to 48. Your domain doesn’t need to move at the same time as your hosting, you can point it at a new host without a formal transfer, which is worth knowing if you’d rather handle buying or transferring a domain as a separate step later.

If you’re running a store, export your product catalog as a CSV (Comma-Separated Values) too, as an extra safety net alongside the file and database transfer.

Picking the right GoDaddy alternative for your site

Most of the six options above solve the same core complaints. The real question is which platform matches how your site actually gets used.

If you’re a blogger or content creator

Priority is a smooth writing and publishing workflow. SiteGround covers the basics by default, daily backups, an in-house WAF, and AI anti-bot protection, with Site Scanner’s daily malware checks available as an add-on if you want that layer too. Bluehost’s WordPress backing and DreamHost’s included daily backups both make sense here. If you pick DreamHost, remember DreamShield, its advanced malware scanning, costs extra, though basic protection is included.

If you’re selling online

This is where reliability matters as much as features, since a broken checkout costs more than a renewal fee ever could. SiteGround’s ecommerce and email marketing live in the same account as hosting, so there’s nothing extra to piece together as the store grows, no re-platforming, no new tier unlocking a tool you already needed. As sales pick up, the plans scale with the store rather than forcing a switch to a different product entirely.

If you’re an agency managing multiple client sites

Client needs vary, so consistent tooling across sites matters more than any single feature. SiteGround lets you manage every client site from a single dashboard, add team members as collaborators on any site, and, on GoGeek plans and higher, give clients white-label access to their own Site Tools with no SiteGround branding in sight. Speed and security matter more here too: a compromised site reflects on the agency, not just the client.

Storm Design, for instance, a Maltese agency, moved its full portfolio to SiteGround after a hack took 85 sites offline at once. A year later, the agency manages 200+ sites with zero hosting emergencies and zero support calls. Founder Jesmond Darmanin sums up his experience:

“Once I moved to SiteGround, I managed to retain all of the clients I have, and I also managed to get back some of the clients that had complained before.”

If budget is the deciding factor

Even the leanest setup benefits from backups, security, and speed included rather than added on later, since that’s exactly where a tight budget gets squeezed the hardest if something’s missing. SiteGround’s entry plan covers all three by default. A lower sticker price elsewhere is worth weighing only once you know what it doesn’t include.

Breaking up with GoDaddy? Here’s your next move

Whichever of these GoDaddy alternatives fits, the switch itself is rarely as disruptive as it looks once DNS, email, and files are mapped out ahead of time. 

SiteGround stands out on this list mainly because it’s the one place a switcher gets hosting and a website builder included, backed by security and caching that work automatically rather than needing manual setup, with ecommerce, email marketing, and AI tools available on the same account rather than pieced together from separate providers.

[86]

Frequently asked questions about GoDaddy alternatives

Some shared hosts run Node.js. Most still don’t. The difference isn’t the price of the plan, it’s the runtime model: PHP discards your application’s state at the end of every request, while Node keeps one persistent process running and waiting for requests. Supporting Node.js means supervising that process.

Almost every answer you’ll find about Node.js on shared hosting was written before that supervision existed.

What “supports Node.js” actually means

The phrase covers two different things, and conflating them is why forum answers often contradict each other. The first is availability: Node exists on the server and you are free to use it, but starting your application, keeping it alive, and pointing a domain at it are all your problems. The second is execution: the host runs your application for you, as a supervised process that stays up, answers on your domain, and starts again by itself when something goes wrong.

Only the second one is hosting. The first is a toolbox, not a service.

That explains the pattern across the types of web hosting sold as “Node-friendly”. A host can truthfully say Node is installed while offering nothing that keeps your application running. Started by hand, it stops the moment the connection that started it closes, because nothing was ever watching it.

A host that genuinely supports Node.js provides all of the following:

• A process supervisor that starts the app and restarts it if it exits
• A web server in front of the app, mapping your domain to it
• A selectable Node.js runtime version
• A dependency step that installs what your package.json declares, using npm, pnpm, or yarn
• A way for the platform to work out which file boots your app, whether it detects it or you set it
• Environment variable storage outside your repository
• Build and deployment logs you can read when something fails

If a plan description mentions no process manager and no way to deploy an application, it’s offering you a binary, not a runtime.

Why shared hosting was built for PHP, not Node.js

Shared hosting was designed around a request model Node.js doesn’t use. The standard stack puts hundreds of accounts on one machine and stays stable because no single site holds resources between visitors. That assumption is baked into how shared hosting allocates memory, which is why Node needed a separate mechanism rather than a config flag.

How PHP releases your application’s memory after every request

A PHP request has a short, bounded lifecycle. A visitor hits the page, the web server hands it to a worker process that is already running and waiting, the worker loads the script, runs it, returns HTML, and then releases everything that script allocated. The worker itself stays alive and picks up the next request. What gets discarded is your application’s state, not the process holding it. That’s why one server can host hundreds of accounts: only the sites being visited consume anything. The per-request lifecycle in PHP 8.4 is a resource isolation strategy as much as an execution one.

Node.js inverts it. Your app starts once, holds its dependencies and state in memory, and answers every request from that same resident process. It consumes its memory footprint at 3 a.m. with zero visitors exactly as it does at peak.

What happens when a long-running process crashes

An unsupervised Node process that throws an unhandled exception doesn’t return a 500 and recover. It exits, the app stops answering, and every request after that fails until someone restarts it manually.

PHP has no equivalent failure mode. A fatal error kills one worker, the next visitor gets a fresh one, and nothing needs to be watching. That’s the problem a host solves before it can sell Node.js on a shared plan: something must monitor each application, restart it on exit, cap what it consumes, and stop one account’s memory leak from taking the neighbors down with it.

What changes on a host that does support Node.js

The host adds an application layer above the web server, and it does the supervision your app would otherwise need a VPS and PM2 to get. It’s the same division of labor that separates managed from unmanaged hosting: the supervision is the product, not something you configure.

That trade runs further than it first looks. The control panel covers the whole deployment, and the familiar hosting tools sit underneath it if you want them: a file manager, scheduled jobs, SSH access to your own account. What you do not get is a server to administer. Nobody is asking you to patch an operating system, configure a process manager, or decide how your app comes back after it falls over. Whether that reads as freedom or as a missing feature is the clearest signal of whether this kind of hosting is for you.

You set a handful of things in a control panel and the platform handles the rest:

• Runtime version. Which Node.js release the app runs on, selected per project rather than per server.
• Framework preset. The platform recognizes what you have built and fills in the build settings that suit it. You can override them, and the file that boots the app is worked out for you.
• Dependencies. The platform installs what your package.json declares, using the package manager you pick and produces the node_modules tree at deploy time.
• Connecting to the web server. You don’t configure this. The platform runs a web server in front of your app, connects the two, and maps your domain to it.
• Environment variables. Credentials and API keys live in the panel, not in your repository.

Where a shared plan can (and can’t) run a Node app

Two questions decide this, and most articles only ask the first. The first is whether your app is request-response or persistently connected. Request-response workloads fit shared plans well, and anything that holds an open connection to each client doesn’t, at any price tier, on any shared host.

The second gets asked far less often and matters just as much: how much does your app need you to operate it once it is live? A managed platform runs your code, not your server. If your app assumes it can reshape the server underneath it, or that something is watching the process on your behalf, that is the constraint worth weighing, more than the framework it happens to be written in.

Two verdicts you should reach without asking support. If your app answers HTTP requests and returns data or HTML, a shared plan carries it. If it pushes data to connected clients in real time, no shared plan will.

The second one catches people deploying something built with an AI tool. Most output from vibe coding workflows is a standard Express or Next.js project and deploys without incident. The exceptions reached for Socket.io because the prompt said “live”.

Ready to deploy rather than evaluate? This article covers whether a shared plan fits your app. For the step-by-step walkthrough, follow How to create a Node.js project in the knowledge base.

How SiteGround compares to Hostinger and app platforms

Two categories of providers answer this query, but they approach Node.js from different directions. Traditional web hosts add Node.js to a broader hosting account that can also run websites, databases, email, DNS, backups, and other services. App platforms put application deployment and runtime management at the center of the product.

The right choice depends both on what your application requires and what else you want the same hosting account to handle, which is an important part of choosing a web hosting partner.

Shared hosts: SiteGround, Hostinger, Namecheap

All three provide a managed interface for running Node.js applications, but their plan limits, deployment workflows, databases, and networking restrictions differ.

• SiteGround. Node.js is available from GrowBig upward, with up to 5 projects on GrowBig, 10 on GoGeek, and unlimited projects on Cloud. Apps can be deployed from GitHub with automatic redeployment or uploaded manually, with configurable build settings and deployment logs. MySQL and PostgreSQL are both available.
• Hostinger. Managed Node.js applications are available on Business Web Hosting and Cloud plans. It supports GitHub deployment, file uploads, configurable builds and managed MySQL. Incoming WebSocket connections aren’t supported on Web and Cloud hosting, so applications that require them need a VPS or another platform.
• Namecheap. Node.js is available on shared hosting through cPanel’s Setup Node.js App tool. PostgreSQL is also available on some shared plans, alongside MariaDB.

Database support is one practical difference. SiteGround provides PostgreSQL directly with its hosting, while Hostinger’s Web and Cloud plans provide MySQL and require an external service for PostgreSQL. That matters if your application is already built around Postgres and you want to keep the database inside the same hosting environment.

App platforms: DigitalOcean App Platform and Fly.io

App-focused platforms generally give you more flexibility around application runtimes, real-time connections, scaling, and deployment architecture. DigitalOcean App Platform supports WebSockets and horizontal scaling, while Fly.io lets you distribute and scale application Machines across regions.

The tradeoff isn’t simply managed versus unmanaged hosting. These platforms manage a substantial amount of infrastructure too. The difference is what they manage around your application.

A traditional hosting account is designed to bundle the other services a website commonly needs alongside the application. An app platform is designed primarily around deploying and operating the application itself, with databases, email, storage, domain registration, and other services added or connected according to the architecture you choose.

That makes the decision less about which category is universally more capable and more about what you want the hosting product to do. If Node.js is one part of a broader website setup, an integrated hosting account can reduce the number of systems you need to manage. If the application needs capabilities such as incoming WebSockets, more flexible scaling, or greater runtime control, an app-focused platform may fit the architecture better.

What you can’t do on any shared plan

WebSockets are not supported on any SiteGround plan. The documented alternative is long polling over standard HTTP and HTTPS, which is fine for a notification badge or a status check every few seconds, but not optimal for a chat app or a collaborative editor.

Three more limits apply across the whole shared hosting provider category:

• No custom inbound ports. Anything that expects to open its own listener for incoming connections won’t start.
• No root. You get SSH access to your own account and a file manager, so your project’s files are yours to read and change. What you can’t do is install system packages or alter how the server itself is configured.
• A fixed resource ceiling. A shared plan is a fixed slice of a shared machine, and an app that outgrows it wants a different tier rather than tuning.

If any of these is a hard requirement, upgrade the infrastructure instead of working around it. Reading the comparison of shared hosting against a VPS beats discovering the limit in production.

Node.js hosting on SiteGround

Plan tiers and project limits

StartUp does not support Node.js. Node.js availability starts on GrowBig and continues through GoGeek and Cloud.

All extra services such as email, SSL, CDN and security features are included in all tiers, at no additional cost.

Deploying via GitHub or ZIP upload

There are two deployment paths, and the choice is worth making deliberately.

• Connect a GitHub repository. Every push to the linked branch rebuilds and redeploys automatically. This is the path for anything under active development.
• Upload an archive. The source goes up manually as a .zip, .tar.gz or .tgz file, with no auto-deploy. Every update is another upload.

Projects are created in Client Area > Websites > Node.js Projects, where you manage status, primary domain, and deletion. Deployment method, build settings, environment variables, and deployment logs live in Site Tools > Node.js.

Databases, domains, and what’s included

Every project launches on an auto-generated temporary domain, so the app is reachable and testable before any DNS points at it. You attach your own domain whenever you’re ready, which also lets a client review a staging URL without touching their live records.

MySQL and PostgreSQL are both created and managed from Site Tools. The plan also includes a free domain, email on that domain, SSL, the SiteGround CDN, daily backups, and WAF and DDoS protection.

A Node.js project isn’t a separate product here. It sits in the same account as your WordPress sites and static pages, sharing the same domain, email, and database tooling. If your app is a request-response API or a server-rendered front end, and you would rather not be responsible for the server underneath it, a shared plan is a real home for it.

The remaining choice is mostly about scale. GrowBig supports up to 5 Node.js projects, while GoGeek supports up to 10, with the rest of the hosting stack managed alongside them. If that integrated setup fits how you want to run your apps, compare the SiteGround Web Hosting plans and choose the tier that matches what you’re building.

[86]

Frequently asked questions