Picking a host feels like a technical decision, but it is really a product decision made early that compounds through every deployment, every traffic spike, and every late-night incident. The options span from free CDN tiers to bare metal, and the right fit depends on what you are shipping and how much of the infrastructure you want to own.
What the categories actually are
The hosting market organises into four practical tiers, and the lines between them matter more than the marketing names vendors use.
Static and CDN hosting serves pre-built files from edge nodes close to visitors. There is no server process running your code on each request. Platforms like Vercel, Netlify, Cloudflare Pages, and GitHub Pages fall here. Your build pipeline produces HTML, CSS, JavaScript, and assets; the host distributes them and handles caching, HTTPS, and preview environments. The operational surface is close to zero.
Platform-as-a-Service (PaaS) runs your application as a container or process. You push code; the platform handles provisioning, scaling, TLS, and the runtime. Heroku is the reference, but Render, Railway, and Fly.io have largely taken over that positioning. You get a real server without managing the server.
VPS and cloud compute give you a virtual machine and hand you root access. You decide the OS, the web server, the process manager, and the firewall. Providers include DigitalOcean Droplets, Linode (now Akamai), Hetzner, and the big three (AWS EC2, Google Compute Engine, Azure VMs). You own everything, including uptime.
Shared hosting puts your files on a server shared with hundreds of other accounts. It is cheap, it is PHP-oriented, and it is where a large portion of the web still runs behind the scenes. For straightforward WordPress sites and small business microsites, it remains a rational choice.
Static hosting: the default for most projects
If you are building a marketing site, a documentation site, a portfolio, or a JAMstack app with an external API layer, static hosting is the answer. Cost ranges from free to a few dollars a month at most scales that do not involve millions of daily visitors. Edge distribution means your files are already where your visitors are, which is a floor-level win for performance before you write a single line of optimisation code.
Static hosting wins on simplicity, cost, and performance. Choose it by default and move up the stack only when the constraints actually hurt.
The trade-off is discipline in what you ask the server to do. A static site cannot execute arbitrary server-side logic at request time. You can work around this with serverless functions, but once your business logic grows complex enough that you are maintaining a significant functions layer, you are paying PaaS complexity at CDN pricing. At that point, a proper PaaS becomes the cleaner answer.
Static hosts pair well with modern frameworks. Astro, Next.js in static export mode, SvelteKit, and Eleventy all produce outputs that deploy cleanly here. If your Figma-to-production workflow ends in a marketing site or a campaign page, a static host is almost certainly the right destination. It also fits naturally with utility-first styling pipelines: the production considerations we covered in Tailwind CSS in production apply directly to a static deploy.
PaaS: the right tier for applications with state
When your project needs to persist data between requests, run background jobs, handle webhooks with side effects, or maintain WebSocket connections, you need a real process. PaaS platforms sit between owning a server and paying for managed cloud complexity you do not need yet.
Render is worth naming specifically: it handles web services, background workers, databases, and cron jobs from a single config file with predictable pricing. Railway and Fly.io are comparable. The experience is close to “push code, get URL,” which is what developers hoped Heroku would stay before its pricing changed the calculus.
The cost is more than static hosting but usually less than managing your own VPS once you account for the engineering time involved in running infrastructure. You trade configuration control for not thinking about nginx configs, certificate renewals, or kernel updates.
If a project needs server-side form processing, email queuing, or rate limiting, PaaS fits better than trying to wedge everything into serverless functions. Our post on form backends for static sites covers the decision point where a lightweight PaaS service makes more sense than a third-party form SaaS.
VPS: the right choice for control and cost at scale
A Hetzner CX22 runs around four euros a month for two vCPUs and 4 GB of RAM. For that, you get a machine you configure as you need. When you are running multiple small apps, a VPS with a reverse proxy and process manager often costs less than running each app on a PaaS with separate billing.
The hidden cost is time. You handle monitoring, log rotation, firewall rules, and system updates. You need a plan for when the disk fills or a process crashes at 3am. This is a sensible trade for teams with a dedicated ops person or engineers who find infrastructure genuinely interesting. It is not a sensible trade for product teams trying to ship features.
A VPS also makes sense when you need a specific runtime, specific software versions, or configuration that a platform’s abstractions cannot express. Some legacy integrations simply require access to the system level.
Shared hosting: narrow but legitimate
Shared hosting belongs in one specific situation: a site that mostly serves static content, does not get much traffic, and needs the lowest possible monthly cost. WordPress on shared hosting is how most small businesses run their web presence. It works.
The limits are real. You cannot install arbitrary packages, your performance depends partly on your neighbours, and you have no control over the server environment. For any project where performance matters or where you push deploys frequently, shared hosting will become a problem within a few months.
How to choose
Start with the simplest tier that covers your actual requirements, and move up when the constraints genuinely bite, not in anticipation of them.
- Static hosting if the project can be pre-built: marketing sites, documentation, portfolios, anything where pages do not need real-time server state.
- PaaS if you need a persistent process: database-backed apps, background jobs, webhooks with side effects.
- VPS if you are consolidating multiple apps, need system-level configuration, or are managing costs at a scale where PaaS pricing compounds.
- Shared hosting only for straightforward WordPress or legacy PHP sites where cost is the primary constraint.
Over-building is as common as under-building. Reaching for container orchestration because the project might scale someday is a failure mode with real costs in setup time and ongoing complexity. Match the tier to where the project is now.
How Strynal approaches hosting
At Strynal, the hosting decision is made during the scoping phase, not as an afterthought after the code exists. Static hosting is the default for the sites we build through our websites and apps practice, because most brand and marketing sites have no reason to run a server process on every request. When a project does need server-side state, we choose a PaaS that keeps operational overhead low while the product is still finding its footing.
We do not recommend platforms we do not use ourselves. When the choice has real implications for long-term cost or performance, we explain the trade-offs plainly and let the project’s requirements drive the decision. If you are scoping a build and are not sure which tier fits, that is a straightforward conversation to have early.