How to Host Your Cloud Portfolio: Options and Best Practices

Hosting your cloud portfolio means making your projects accessible and demonstrable, not just stored in a repository. But “hosted” means different things for different project types — an API, an infrastructure project, and a Kubernetes deployment all need different approaches. This guide covers the practical options and honest trade-offs for each.

Does your portfolio project need to be live?

The short answer: not necessarily, but it helps for certain types of projects.

For most cloud engineering and DevOps roles, what matters is:

The code is in a public GitHub repository
The README explains the architecture and decisions
The infrastructure is provisioned with code that can be reproduced

A hiring manager reviewing your portfolio will rarely click a live URL — they will read the README and look at the code. An impressive architecture deployed from a well-written README is more valuable than a live endpoint that returns a blank page.

However, for web-facing projects — static sites, APIs, dashboards — having a live URL adds a small but real signal: “this is working, deployed infrastructure, not just code.” And for take-home technical challenges, a live deployment is often specifically required.

Hosting static sites and frontends

GitHub Pages

GitHub Pages hosts static HTML/CSS/JS directly from a repository. Free, zero configuration, and automatically redeployed when you push to the main branch. Appropriate for a personal portfolio website or project documentation.

The limitation: GitHub Pages is a hosting service, not a cloud infrastructure demonstration. Hosting your portfolio website on GitHub Pages while your cloud projects remain in repositories is perfectly reasonable — you do not need to self-host your portfolio site on AWS to prove a point.

Netlify or Vercel

Netlify and Vercel provide free static hosting with automatic deployments from GitHub. Both support custom domains and HTTPS automatically. Good options for frontend-heavy portfolio projects.

S3 + CloudFront (AWS) or Cloud Storage + CDN (GCP)

Hosting a static site on S3 with CloudFront distribution is a genuine cloud portfolio project — it demonstrates you can configure object storage permissions, CDN behaviour, and HTTPS certificate management. The hosting is cheap: a static site with low traffic costs pennies per month on S3. Keep billing alerts active.

This is the recommended approach if you want the hosting itself to be portfolio material.

Hosting APIs and backend services

Serverless: leave it running

Serverless functions (Lambda, Cloud Functions) are effectively free to leave running at portfolio scale — AWS Lambda’s free tier covers 1 million invocations per month. Deploy your serverless API and leave it running. Include the live endpoint URL in the README. The cost will be negligible.

Containers: use Cloud Run or App Runner

GCP Cloud Run and AWS App Runner scale to zero when not receiving traffic, meaning they cost nothing when idle. For a portfolio API running in a container, both are good hosting choices — you get a real cloud service URL and no idle cost.

GCP Cloud Run’s free tier is generous: 2 million requests per month and significant compute time at no charge. For a portfolio project, it is essentially free.

VMs: tear down or use free tiers carefully

Running an EC2 instance or Compute Engine VM 24/7 costs money. AWS’s free tier includes 750 hours per month of a t2.micro for 12 months. GCP’s free tier includes one e2-micro permanently in specific regions.

Use these free tier VMs for portfolio projects if you need them. Set billing alerts before you start. If the free tier expires or you want to host additional VMs, tear them down when not actively demonstrating — do not let VMs run indefinitely at cost for a portfolio project.

Hosting infrastructure projects

Pure infrastructure projects — Terraform modules, networking configurations, security baselines — do not have a “hosted” state in the traditional sense. These projects live in the repository and are deployable from it. The hosting is the repository, not a running service.

The recommended approach for infrastructure projects:

Include the README instructions for deploying to a new account
Consider adding screenshots of the deployed infrastructure (AWS console or GCP console screenshots showing the created resources)
If the infrastructure is too expensive to keep running, document the expected monthly cost in the README and explain that you tear it down after testing

Hiring managers for infrastructure roles understand that you cannot keep a three-tier VPC with NAT gateways running indefinitely for a portfolio project. Documenting the cost and the tear-down decision actually shows cost awareness, which is a positive signal.

Hosting Kubernetes projects

Local cluster documentation

If your Kubernetes project runs on kind or minikube, document the exact steps to deploy it locally in the README. Include the version of kubectl and kind used. A hiring manager should be able to clone the repository and run the project on their machine with the commands you provide.

GKE Autopilot or EKS free tier

GKE Autopilot clusters are charged for the pods they run, not the control plane. Running a small multi-service application on GKE Autopilot can cost under $5 per month at portfolio scale. EKS charges $0.10 per hour for the control plane — a full month costs about $72, which is significant. For persistent hosting, GKE Autopilot is more cost-effective.

If you want a live Kubernetes cluster as part of your portfolio, spin it up for demos and tear it down afterward if cost is a concern. This is a legitimate practice — document it.

Hosting monitoring dashboards

Grafana offers a free managed Grafana Cloud tier with 10,000 metrics, 50 GB of logs, and 50 GB of traces — enough for a portfolio project. This is the simplest way to have a live, shareable Grafana dashboard without self-hosting.

Include a screenshot of your dashboard in the README (so hiring managers can see it without needing an account) and optionally a link to the live Grafana Cloud instance.

Managing costs across multiple projects

Running multiple portfolio projects simultaneously adds up. Practical rules:

Always set billing alerts before deploying any project — $1 and $5 alerts will catch accidental spend early
Use serverless and scale-to-zero services wherever possible — they cost nothing when not in use
Tear down VMs, databases, and Kubernetes clusters when you are not actively working on or demonstrating them
Use free tier services where they genuinely fit — but understand their limits so you do not generate unexpected charges
Document expected monthly costs in your README — this is a positive signal, not a weakness