The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
To host a website, put its files or application on a hosting service, then (optionally) connect a domain name by configuring DNS. A plain HTML, CSS, and JavaScript site can use static hosting. Server-side code, logins, uploads, or a database require an application-capable host and usually additional services.
Understand the four parts of a public website
- Site files or application: HTML, CSS, JavaScript, images, and any server-side code.
- Web host: the service that stores files or runs your application and serves it to visitors.
- Domain: the human-readable address, such as
example.com. Buying a domain alone does not publish a website. - DNS: the system that directs the domain (or a subdomain such as
www) to your host. An A record maps a hostname to an IP address; a CNAME creates an alias. Google Cloud explains these record types and DNS behavior.
You can publish some beginner static sites on a provider subdomain without buying a custom domain. A custom domain is optional for that workflow but typical for a public business, portfolio, or publication.
Identify what your site must run
Static sites
Static hosting serves files as written: HTML, CSS, client-side JavaScript, images, fonts, and downloads. It does not execute PHP, Python, Ruby, Node.js server code, or other server-side scripts. Google Cloud’s static-website documentation explicitly limits this route to client-side files and warns that the content is public to the internet: Host a static website.
Dynamic or server-side sites
Choose an application-capable service when the site needs server-side rendering, an API, authentication, payments, personalized pages, file uploads, scheduled jobs, or a database. Your host must support the framework and runtime version you plan to use; the database and object storage may be separate managed services. A static object-storage bucket alone cannot run that code. Google’s overview distinguishes static pages from sites requiring robust server-side interaction: Website hosting.
Choose a hosting approach
| Approach | Suitable for | What you configure | Important limitation or trade-off |
|---|---|---|---|
| Managed static hosting | HTML/CSS/JavaScript sites and many frontend builds | Upload or deploy the build output, then attach a domain | Cannot execute server-side scripts or provide a database by itself |
| Static object storage | Public static files and large media collections | Bucket permissions, website routing, and often a CDN or load balancer | Cloud Storage’s documented route does not provide custom-domain HTTPS alone; it also makes content public. Google’s guide |
| Managed application hosting | Server-rendered apps, APIs, and dynamic frameworks | Runtime, build/deploy settings, environment variables, data services, and domain | Usage and runtime configuration affect cost and operations |
| Cloud architecture with CDN/load balancer | Sites needing custom routing, TLS termination, caching, or separate compute and storage | Compute or storage, CDN/load balancer, certificates, DNS, monitoring, and billing controls | More components and decisions to maintain |
| Self-managed server or VPS | Applications needing operating-system-level control | Server hardening, web server, runtime, firewall, updates, backups, TLS, DNS, and monitoring | You assume substantially more maintenance and failure-recovery responsibility |
These are architecture choices, not a universal provider ranking. Compare support for your runtime, deployment method, certificates, backups, scaling, portability, and billing model before signing up.
Examples of documented provider paths
Firebase Hosting for a static or mixed frontend
Firebase’s quickstart documents deployment of static assets and dynamic content, with CDN backing, custom domains, and SSL served by default. It requires a Firebase project and the Firebase CLI. Firebase also provides project subdomains at no cost on web.app and firebaseapp.com. Follow the current workflow at Get started with Firebase Hosting.
Google Cloud Storage for static files
Google Cloud Storage can serve static files, but the documented custom-domain route needs additional HTTPS infrastructure such as an HTTPS load balancer. It is not a drop-in host for PHP or other server-side scripts. See Host a static website.
AWS S3 with CloudFront and Route 53
AWS’s example combines an S3 static site with Route 53 DNS and CloudFront for SSL/TLS delivery. Billed components can include domain registration, S3 storage, requests and data transfer, plus CloudFront requests and transfer. The setup is described in Getting started with Amazon Route 53; do not treat its example pricing language as a universal hosting price.
Cloudflare DNS and Pages
Cloudflare says a domain is the address visitors type and a host keeps the site online. Cloudflare does not host most websites, although Cloudflare Pages can host JAMstack sites, and Cloudflare documents Universal SSL for Cloudflare domains. Its domain onboarding explanation is at Domains and Add a site.
Deploy a website: the practical sequence
- Inventory requirements. List the framework, language runtime, server-side features, database, uploads, expected traffic, private data, and required regions.
- Select a compatible host. For a simple static site, use managed static hosting. For server-side behavior, choose a service that explicitly supports the runtime and data services.
- Prepare the deployable files. For a hand-written site, confirm that the entry file (usually
index.html) and asset paths work from the intended public root. For a framework, run its documented production build and deploy the resulting output or application. - Create the host project. Configure the project, application, bucket, or site according to the provider’s current documentation. Keep secrets in environment variables or a secret manager, never in public JavaScript.
- Deploy through the provider workflow. Use the host’s CLI, Git integration, or upload process. Firebase’s documented CLI flow starts with a Firebase project and then initializes and deploys Hosting.
- Add the custom domain in the host dashboard. The host will display the exact DNS records it expects. Copy those values rather than guessing.
- Publish the DNS records. At your registrar or DNS provider, add the requested A, AAAA, CNAME, TXT, or verification records. Keep unrelated mail records (such as MX) intact.
- Wait for DNS propagation. Resolvers cache answers according to TTL, so different networks may see old and new records for a while. Check both the apex domain (
example.com) andwww.example.comif both should work. - Verify HTTPS and redirects. Open the actual hostname over
https://, confirm the certificate has no warning, test the intended HTTP-to-HTTPS redirect, and check that every page and asset loads. - Review operations before launch. Set billing alerts or limits where available, confirm backups and rollback procedures, enable logs, and document who can change DNS and deployment settings.
Configure DNS without breaking the site
Use the host’s exact record instructions
Some hosts give an IP address for an A record; others give a hostname for a CNAME; domain verification may require a TXT record. The correct values depend on the provider and whether you are connecting the apex, www, or another subdomain.
Handle the apex and www deliberately
Decide which address is canonical, configure the other to redirect or alias as the host supports, and test both. An A record is commonly used for an apex address, while a CNAME is commonly used for a subdomain, but follow your provider’s instructions because some platforms use special flattening or verification records.
Allow for cached answers
DNS is distributed and cache-based. A successful change at your registrar does not mean every resolver has refreshed immediately. Do not repeatedly replace records during propagation; verify from more than one network and use the provider’s domain-status tool.
HTTPS depends on the hosting architecture
Do not assume that storing files automatically gives your custom domain a certificate. Firebase states that Hosting serves content over SSL by default. In Google’s Cloud Storage static-site route, custom-domain HTTPS requires an additional service such as an HTTPS load balancer. AWS’s documented path uses CloudFront for SSL/TLS. In every case, test the certificate on the real hostname visitors use, not only on a provider preview URL.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Estimate the total cost
There is no single price to host “a website.” Depending on the architecture and traffic, costs can include:
- Domain registration and renewal for the chosen top-level domain
- Storage and database capacity
- Compute time or always-on instances
- Requests, bandwidth, and CDN transfer
- Load balancers, certificates, logs, backups, email, and other optional services
Google Cloud notes that implementation variables make a universal cost figure inappropriate and points readers to service pricing and its calculator: Website hosting. Estimate expected storage, monthly requests, outbound data, compute hours, and database use, then set alerts or spending limits. Recheck live provider terms before publishing a price because quotas and rates change.
Recommended Free Tools
Pre-launch checklist
- The host supports every language, framework, API, database, upload, and authentication feature required.
- No private key, password, API secret, or private source file is publicly deployed.
- The intended root and
wwwaddresses resolve correctly. - HTTPS works without certificate warnings, and HTTP redirects as intended.
- Navigation, forms, images, downloads, redirects, and client-side routes work in production.
- Error pages and refreshes on deep links behave correctly for a single-page application.
- Backups, rollback, logs, access controls, and ownership of the domain account are documented.
- Billing alerts, quotas, or spending limits are enabled where the provider offers them.
Common failures and the right fix
The domain shows an old site or an error
Check whether the apex and www records point to different destinations, whether a stale record remains, and whether DNS caches have expired. Compare the records with the host’s current domain-verification page.
HTTPS is missing or warns about the certificate
Confirm that the custom domain was added and verified in the host, that the required DNS records are present, and that you are opening the exact hostname covered by the certificate. A static bucket may need a CDN or HTTPS load balancer rather than a direct custom-domain mapping.
Pages load but server features fail
You probably deployed static files to a static-only service. Move the server-side code to an application-capable runtime and configure its database, environment variables, and API routing.
A single-page app returns “not found” after refresh
Configure the host’s rewrite or fallback rule so application routes serve the frontend entry file, while real asset paths and API paths remain distinct. Use the provider’s framework-specific routing guidance.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The bill is higher than expected
Inspect bandwidth, request, compute, database, logging, and CDN usage separately. Add caching where appropriate, remove unnecessary transfers, and set alerts before increasing limits.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
