DEV Community: Mehedi Mansur Rafi

The cheapest good way to host a small business website

Mehedi Mansur Rafi — Wed, 04 Nov 2026 05:05:11 +0000

Every small business owner I talk to asks the same question in a different way: "Where should I put my website so it stays online, loads fast, and does not eat money every month?"

Cheap hosting is easy to find. Cheap hosting that is still good in year two is the real problem. This post walks through the two routes that make sense for a small business site, what each one actually costs you over time, and how to pick.

A note before the details: some links in my posts may be affiliate links. I only write about services I have checked carefully, and I will say plainly when a recommendation is based on a provider's published terms rather than my own usage.

What a small business website actually needs

Strip away the marketing pages and a business site needs five things:

HTTPS (SSL) — free at any decent host now. If a plan charges extra for SSL, walk away.
Backups you can restore — not just "backups exist", but a button you can press to roll the site back.
A renewal price you can live with — the first-term price is advertising. The renewal price is the real price.
Support that answers — when your site is down before a workday, a slow ticket queue costs more than the hosting saved you.
Room for one step of growth — a contact form today, a booking page or small shop next year, without migrating on day one.

Keep those five in mind and most "unlimited everything for $1" offers sort themselves out.

Route 1: Shared hosting (the budget route)

Shared hosting means your site lives on a server with many other sites, and the provider manages everything: updates, security patches, the control panel. Hostinger is the name that comes up most in this category right now, and its published model is the standard one for budget shared hosting: a low introductory price when you pay for a long first term, then a higher renewal price afterwards.

Who it fits: a brochure site, a blog, a portfolio, a small shop that is just starting. WordPress and simple PHP sites run fine here.

What to check before you buy:

The renewal price, not the banner price. Work out the cost over three years, not three months.
How long the first term must be to get the low price. A 4-year commitment is a real decision, not a discount detail.
Whether backups are included in the plan tier you picked, or only in the tier above.
Whether business email is included or sold separately.

The honest trade-off: you give up control and some speed headroom, and in exchange you pay the least and manage almost nothing. For a site whose job is to be found and to look trustworthy, that trade is usually right.

Route 2: Managed cloud hosting (the growth route)

A step up is a cloud server (a VPS) with a management layer on top. Cloudways is the example I use when explaining this route: you pick a cloud server from providers like DigitalOcean or Vultr, and their platform handles the server setup, updates, caching, and backups for a monthly fee on top of the server cost.

Who it fits: a site that runs custom code (for example a Laravel application), a shop that is starting to sell seriously, or any site where slow loading directly costs orders.

What to check before you buy:

The total monthly number: platform fee plus server size. It is monthly, with no long commitment, which makes the real cost easier to see than an intro offer.
Email is usually NOT included. Budget for a separate email service if the business needs mailboxes on the domain.
Backups and staging (a safe copy of the site to test changes on) are the features you are really paying for. If you will never use staging, you may be paying for headroom you do not need yet.

The honest trade-off: it costs several times more than budget shared hosting, and in exchange you get speed, scaling, and tools that matter once the site earns money.

The costs people forget

Whichever route you pick, these are the lines that surprise people later:

Renewal jumps. A plan that starts at a few dollars a month can renew at two or three times that. Put the renewal date and price in your calendar the day you buy.
Domain privacy and renewals. The domain itself renews every year, and privacy protection is worth having.
Your own hours. The cheapest plan that takes you a weekend to fix is not cheap. Price your time honestly.
Migration pain. Leaving a host is easiest before you need to. Keep your own copy of the site's files and database from day one, outside the host.

A simple way to decide

Your site is pages, photos, a contact form, maybe a small shop starting out → shared hosting (route 1). Spend the savings on a good design and your Google Business Profile.
Your site runs an application, takes bookings or payments you depend on, or you expect real growth this year → managed cloud (route 2). The monthly cost is a business expense, and downtime is the expensive option.
You are not sure → start on route 1 with a short enough term that changing your mind is painless, and move up when the site gives you a reason. Moving a simple site is a routine job; I wrote up the general shape of putting a site online in my previous post.

If you would rather hand this over

Choosing the host is the easy part. Setting the site up cleanly, connecting the domain, and keeping it updated is the ongoing work. If you want help with that, I take small website jobs and monthly care work through Upwork and Fiverr — the links are on my profile here. Tell me what the site needs to do, and I will tell you honestly which of the two routes above it belongs on, including when the answer is the cheaper one.

How to put a Laravel website online, step by step

Mehedi Mansur Rafi — Wed, 04 Nov 2026 03:39:00 +0000

Disclosure: some links in this post may be affiliate links. If you buy hosting
through one of them, I earn a commission and you pay the same price. I only
link to services I would use for my own projects.

A Laravel app that runs on your laptop is not finished. It is finished when a
stranger can open it in a browser. This is the full path I use when I deploy
Laravel projects for myself and for clients, written in the order I actually
do the work.

What you need before you start

A domain name. Any registrar works.
A server or hosting account that runs PHP 8.2 or newer and MySQL.
Your Laravel project in a Git repository, or as a clean zip without vendor/ and node_modules/.

For a small Laravel site you have two sane choices. Shared hosting is cheap
and fine for low traffic, but you get no SSH on most plans, and that makes
Laravel painful. A managed cloud server costs a bit more and removes most of
that pain. This walkthrough uses Cloudways, because it gives you a real
server with SSH, Git deployment and SSL handled, without making you
administer the machine itself. Their plans are listed at
https://www.cloudways.com (plain link).

Step 1: Create the server and the application

In Cloudways, launch a server (DigitalOcean or Vultr, 1–2 GB RAM is enough
for a small app), then add an application and choose "Custom PHP App" or the
Laravel option if it is offered. Cloudways creates the database, the SFTP
user and the folder structure for you. Write down three things: the server
IP, the application public path (it ends in public_html), and the database
name, user and password from the application's Access Details page.

Step 2: Get your code onto the server

Two ways work well:

Git: add the server as a deployment target and pull your repository into the application folder. Best if you deploy often.
Upload: zip your project locally (without vendor/), upload it through SFTP or the file manager, extract it into the application folder, then run composer install over SSH.

After the code is there, run these once:

composer install --no-dev --optimize-autoloader
cp .env.example .env
php artisan key:generate
php artisan storage:link

Step 3: Point the web root at the `public` folder

This is the step people skip, and then every route returns 404. Laravel's
entry point is public/index.php. The web server must serve the public
folder, not the project root. On Cloudways the application already serves
from public_html, so make sure your project root sits in public_html and
that public_html/public is not an extra nested level. On shared hosting,
create the subdomain or addon domain with its document root ending in
/public. If you get this wrong, no .htaccess trick will save you.

Step 4: Fill in `.env` for production

Open .env on the server and set the values that matter:

APP_ENV=production
APP_DEBUG=false
APP_URL=https://yourdomain.com
DB_DATABASE=your_database_name
DB_USERNAME=your_database_user
DB_PASSWORD=your_database_password

APP_DEBUG=false is not decoration. With debug on, an error page shows your
file paths, your environment values and parts of your code to anyone who
triggers an error. Turn it off before the site is public, every time.

Then:

php artisan config:cache
php artisan route:cache
php artisan view:cache

Step 5: Create the database tables

php artisan migrate --force

--force is required in production; without it Artisan asks for confirmation
and your deployment script hangs. If your host gives you no SSH and no
Artisan, export the SQL from your local database and import it through
phpMyAdmin instead. It is slower and easier to get wrong, which is one more
reason to pick hosting with SSH.

Step 6: Fix file permissions

Uploads made through a file manager often land with permissions the web
server cannot read. The symptom is a white page or a 500 error right after a
"successful" upload. The fix:

Files: 644
Folders: 755
storage/ and bootstrap/cache/ must be writable by the web server.

chmod -R 755 storage bootstrap/cache

Step 7: Connect the domain and turn on SSL

Point your domain's A record to the server IP. In Cloudways, add the domain
under Domain Management for the application, then issue the free Let's
Encrypt certificate from the SSL page. Wait for DNS to spread (a few minutes
to a few hours), then open the site with https:// and check that the padlock
shows and no page element still loads over plain http://.

Step 8: Add the scheduler and queues

Laravel's scheduler needs one cron line on the server:

* * * * * cd /path-to-your-app && php artisan schedule:run >> /dev/null 2>&1

Cloudways lets you add this from the application's Cron Job Management page.
If your app sends mail or does slow work in queues, run a queue worker under
a supervisor (Cloudways has one built in) instead of letting requests wait:

php artisan queue:work --tries=3

Step 9: Test like a visitor, not like the developer

Open the site in a private browser window. Register an account. Log out and
back in. Submit every form. Upload a file if your app takes uploads. Then
check on your phone. I test this way because the developer session hides
bugs: you are logged in as admin, your browser has cached assets, and your
.env mistakes only show for guests. Half the deployment bugs I have fixed
for clients were invisible from the developer's own chair.

The short checklist

Code on the server, composer install --no-dev done.
Web root points at public.
.env set, APP_DEBUG=false, key generated.
Database migrated.
storage/ writable, permissions sane.
Domain connected, SSL on.
Scheduler cron added.
Tested logged-out, on desktop and on a phone.

Do those eight and your Laravel site is online in a way that stays online.

I deploy and maintain Laravel websites for small businesses. If your site is
stuck on one of these steps, or you want someone to look after updates,
backups and fixes every month, you can hire me on
Upwork or
Fiverr.