Choosing cloud hosting for a Sri Lankan startup

Start small, but not careless

Early on you don't know your traffic, your final architecture, or even whether the product will survive the next three months. That is an argument for the smallest setup that runs what you have today, not for a cluster you might need next year.

Small does not mean careless, though. The cheap shortcuts that hurt later are rarely about server size. They are things like no backups, the domain registered in a freelancer's personal account, database passwords committed to GitHub, or a setup only one person knows how to deploy. Those cost almost nothing to get right on day one and a lot to fix after launch.

A practical rule: pick the smallest plan or server that runs your product with some headroom, write down what would make you move up (response times, CPU, database size), and revisit it when those numbers change, not before. If you are still deciding between a managed service and running your own server, read managed hosting vs a VPS first.

The five checks before you commit

1. You can pay without a dollar card

Many founders start on a personal card that happens to work abroad. That works until the card expires, hits its limit, or leaves with a co-founder, and then a renewal fails and production goes down. Billing in LKR from a company account removes that risk. If you do pay in dollars, put the card on a company account and set a reminder before it expires. Our hosting cost guide covers the other effects of paying in a foreign currency.

2. Backups exist and you have tested a restore

"We take backups" is not the same as "we can restore". Ask how often backups run, how long they are kept, whether they include the database, and how a restore is requested. Then actually restore one, to a staging copy, before launch. A backup you have never restored is a guess.

3. You can move away without rewriting

Lock-in is rarely a contract. It is code that only runs on one platform. You keep your options open by building on things every host understands:

• A standard database such as PostgreSQL or MySQL, which you can dump and restore anywhere.
• A Docker image or a plain build command, so the app runs the same on a laptop, a host, or a cloud provider.
• Configuration from environment variables, not hard-coded to one provider.
• Platform-specific services (proprietary queues, databases, functions) used deliberately, behind your own code, so swapping them is one module and not the whole app.

If you are packaging the app as containers, our checklist for running Docker in production covers volumes, backups and updates.

4. There is a clear path to more resources

Ask what happens when you outgrow the plan. Can you move up without migrating, re-deploying from scratch or changing your domain setup? Is there a step after the biggest plan? You don't need that step now, but you should know it exists.

5. A real person answers when it breaks

Find out how you reach support, during what hours, and how quickly they reply. Then plan for the hours they don't cover. If your product needs someone on call through the night, that is something to arrange deliberately, whether that is a team member, an alert to a founder's phone, or a provider who offers it.

Who should own the domain, DNS and registrar accounts

The domain is the one asset you cannot replace. Everything else (server, code, database) can be rebuilt from backups. If you lose control of the domain, you lose your email and your address on the web.

• Register the domain in the company's name, or a founder's, using an email address the company controls. Not the agency's or the freelancer's personal account.
• Use a role address such as [email protected] for the registrar, DNS provider and hosting accounts, so access does not leave with one person.
• Turn on two-factor authentication on the registrar, DNS, hosting, GitHub and email accounts. These are the accounts that can take your product offline.
• Give contractors their own access, scoped to what they need, rather than sharing your login. You can remove it when the work ends.
• Turn on auto-renew for the domain and keep the payment method current.
• Keep a one-page record of where the domain is registered, where DNS is hosted, where the app and email are hosted, and who has access to each.

Staging vs production

Production is what your users see. Staging is a copy where you try changes first. You don't need a complex pipeline to have one, just a second environment that behaves like the first.

• Separate databases. Staging should never write to the production database. Test with copied or made-up data.
• Separate credentials. Use test keys for payment gateways and SMS or email providers on staging, so a test run cannot charge a real card or message a real customer.
• Same build. Deploy the same build or image to staging and production, changing only configuration. If they are built differently, staging proves less.
• Keep staging private. Put it behind a password or an IP allowlist so search engines and the public don't find it.

Keep secrets out of the repo

API keys, database passwords and signing secrets belong in environment variables on the server, not in your Git history. Commit an example file that lists the variable names, and ignore the real one:

# real secrets stay on each machine
.env
.env.local
.env.production

DATABASE_URL=postgres://user:password@host:5432/dbname
SESSION_SECRET=change-me
PAYMENT_API_KEY=

Use different secrets for staging and production, limit who can read the production values, and keep a note of which service each secret belongs to so you can rotate it quickly.

What to do before launch day

Work through this list a few days before launch, not the morning of:

1. Restore a backup to staging and confirm the app works from it.
2. Confirm HTTPS works on every hostname you use (with and without www).
3. Lower the DNS TTL on the records you will change, a day or two ahead, so the switch takes effect quickly.
4. Set up uptime monitoring that alerts a person, not just an inbox nobody reads.
5. Make sure errors are logged somewhere you can search, with no secrets or passwords in the logs.
6. Check that transactional email (sign-up, password reset, receipts) actually arrives and isn't in spam.
7. Write down how to roll back the last deploy, and try it once.
8. Agree who is watching on launch day, and who they call if something breaks.
9. Check the production environment variables one last time: no test keys, no debug mode.

Where NevaraCloud fits

For a marketing site or an MVP, our managed plans cover most of this list: billing monthly in LKR with no contract, free SSL and Cloudflare CDN on every plan, and from the Business plan up a MySQL or PostgreSQL database with daily backups kept for 7 days. If your app already runs as containers, we host it on our Docker hosting, quoted in LKR once we see what the containers need. Support is by WhatsApp and email, every day from 9am to 10pm, so plan your own cover for the hours outside that.

If you need root access or custom system software, we don't sell VPS plans, so we aren't the right host. If you already run your own servers and want help setting up deployments or fixing a problem, our deployment services are quoted after we look at the setup. Plan prices are on the pricing page.