How to choose a hosting provider: a no-hype checklist

Picking hosting often turns into comparing entry prices, and that is where the surprises come from: the cheap plan that cannot run your back end, the domain billed separately, the renewal price that doubles. A safer method reverses the order: first what the project needs, then the provider.

The checklist below applies to any vendor and does not name a universal winner, because a static blog and an API with a database need different things.

What does your project need to run?#

This question removes half the options. There are three common cases:

• Static site: ready-made files, no code running on the server. See what a static site is. It is the simplest and cheapest case to host.
• App with a server: Next.js with server rendering, an API in Node.js or Python, an admin panel. It needs an always-on process and RAM.
• App with a database: besides the server, it needs a database (PostgreSQL, MySQL, MongoDB, Redis) that is reachable, ideally close to the app.

If the difference between these cases is still fuzzy, read what web hosting is first.

Which criteria really matter?#

Use this list as a filter. If a provider fails two or more items you care about, drop it.

1. Fit with your stack. Are your language and version (Node, Python, PHP, Java) supported? Traditional shared hosting tends to be strong on PHP and weak on the rest.
2. RAM and CPU. This is the limit that takes most production sites down. Find out whether the figure is per app or a total split across all of them, and whether the provider says what happens when you exceed it.
3. HTTPS included. It is a baseline requirement today. Certificates are issued at no cost by authorities such as Let's Encrypt, which describes itself as "a free, automated, and open Certificate Authority". Charging a lot for a basic certificate is a warning sign. See what SSL/TLS is.
4. Custom domain. Check that the plan accepts your domain and whether domains are sold together with hosting or separately. Domain and hosting are different services. Registering the domain in your own name, not the provider's, makes switching hosts easier later.
5. Logs and metrics. Without logs, a customer is the one who tells you the site is down. Look for real-time logs and a CPU and RAM dashboard.
6. Backups and recovery. Check whether automatic backups exist, how long they are kept and whether you can restore on your own. Test a restore at least once: a backup that was never restored is just an assumption.
7. Uptime and support. Understand what the number promises. At 99.9% per month, the site may be down about 43 minutes (30 days × 24 h × 60 min × 0.1%). See also what 99.9% uptime means. Ask how support responds, and in which language.
8. Easy exit. Can you export the code, the database and the files? Is there a lock-in contract or cancellation fee? Prefer providers where leaving is just a DNS change.

What does it really cost?#

The advertised price is rarely the total. Add up:

• hosting (monthly or yearly);
• domain (billed yearly, and the renewal can cost more than year one);
• a database, if not included;
• overage on traffic, storage or build minutes;
• backups, professional email and a CDN, when billed separately.

Do the math for 12 months and compare totals, not the monthly fee. For numbers by type of solution, see how much website hosting costs and how much a domain costs.

Shared, VPS or platform: which type?#

There is no best type, only the one that fits your time and skills. A cheap VPS gets expensive if you spend your evenings patching it. The full comparison is in VPS, cloud or platform.

Which red flags should you avoid?#

• Promises of "unlimited traffic" or "unlimited resources" with no written fair-use policy.
• An entry price valid only for the first term, with no visible renewal price.
• No mention of RAM or CPU limits.
• No access to logs, or no way to export your data.
• An extra fee to enable HTTPS.
• Comparison pages that are really undisclosed affiliate links.

Which one fits each scenario?#

• Portfolio or static blog: static hosting or a site platform. Cost can be low and HTTPS usually comes ready.
• Business site with a contact form: static plus a form service, or a small app with a back end.
• Store or app with a database: a plan with comfortable RAM, a database close to the app, automatic backups and logs.
• API or bot: an always-on process, automatic restart and logs. Avoid plans that suspend the app when idle.
• A project that will grow: prioritize easy exit and the ability to raise RAM without migrating.

How to do this on Square Cloud#

Square Cloud is self-service hosting: you deploy and control the application. Measured against the checklist above, it covers these points (per the official pages):

• Stack: several runtimes, including Node.js, Python, PHP, Go, Java and static sites (on the static one, nginx is always online serving the files). See the runtimes available today on Runtimes.
• RAM: the plan sets a pool shared across your applications, with a 512 MB minimum per web application. Every plan is paid, and Hobby starts at R$12.49 per month.
• HTTPS and domain: every web application gets a *.squareweb.app subdomain with HTTPS. A custom domain is available from the Standard plan, and it stays registered in your name at your registrar.
• Database: hosting for MongoDB, PostgreSQL, MySQL and Redis from Standard. Hobby does not include a database.
• Logs and metrics: real-time logs and cookie-free web analytics on every plan.
• No suspension: containers stay on, and automatic restart (on by default for dashboard deploys) brings back an application that exits with an error.
• Exit: no lock-in contract.

See the options for websites on the Square Cloud sites page.