If you've built a web app that runs on your laptop, you've done the hard part. Getting it onto the internet so other people can use it? That should be straightforward. And yet, cloud deployment remains one of those topics buried under acronyms, vendor marketing, and a frankly absurd number of configuration options.
This guide cuts through the noise. We'll cover what cloud deployment actually means, how the main models differ, and what matters when you're choosing where to put your code. No fluff, no sales pitch — just the stuff you need to make a good decision.
Cloud deployment is the process of putting your application — code, databases, assets, the lot — onto servers managed by someone else, accessible over the internet. That's it. You write the software. A cloud provider runs the infrastructure. Users hit a URL and your app responds.
The "someone else" part is what distinguishes cloud deployment from the old model of racking your own servers in a cupboard. You're renting compute power, storage, and networking from a provider who handles the physical hardware, power, cooling, and (usually) the operating system patches.
The obvious upside: you don't buy servers. You don't hire someone to replace failed hard drives at 3am. You pay for what you use, scale up when traffic spikes, and scale down when it doesn't. The less obvious upside: most providers run data centres across multiple regions, so your app can be geographically close to your users without you thinking about it.
These three acronyms describe how much of the stack the provider manages versus how much you manage yourself. Think of it as a spectrum from "here's a raw machine, good luck" to "here's a finished product, just log in".
IaaS gives you virtual machines, storage, and networking. You get a blank server (or several) and you're responsible for everything from the operating system upward: installing runtimes, configuring firewalls, deploying your code, setting up monitoring.
AWS EC2, Google Compute Engine, and Azure Virtual Machines are the big examples. DigitalOcean and Linode (now Akamai) sit here too, targeting smaller teams who want something less overwhelming.
IaaS makes sense when you need full control — custom kernel configurations, specific OS versions, unusual networking setups. The trade-off is time. You'll spend hours on infrastructure that has nothing to do with your actual product. For a small team shipping a web app, that's often time you can't afford.
PaaS sits in the middle. The provider handles the operating system, runtime, and usually the deployment pipeline. You push your code (often via Git), and the platform builds, deploys, and runs it. Need a database? Add one with a click or a config file.
Heroku popularised this model. Code Capsules operates here too — you connect a GitHub repo, pick your environment, and deploy. No Dockerfiles, no Kubernetes manifests, no YAML nightmares. The platform handles the rest.
PaaS is the sweet spot for most web applications. You get the speed of deployment without giving up the ability to run real backend code. The constraint is that you're working within the platform's supported languages and configurations. For 90% of projects, that's not a constraint at all.
SaaS is the end of the spectrum where you're not deploying anything — you're using someone else's finished software. Gmail, Slack, Notion. You configure it, you don't code it.
SaaS matters in a cloud deployment discussion because it's often what your users experience. You build the app (using IaaS or PaaS to deploy it), and your customers consume it as SaaS. Understanding where you sit in the stack helps you make better architecture decisions.
Beyond the service model, there's the question of where the infrastructure lives and who shares it.
The default for most teams. AWS, Azure, Google Cloud, and smaller providers all run public clouds. "Public" doesn't mean your data is exposed — it means you share the underlying physical infrastructure with other tenants. Your resources are isolated, but the hardware isn't exclusively yours.
Public cloud is cheap, fast to set up, and scales well. Unless you have regulatory requirements that explicitly forbid shared infrastructure, start here.
A cloud environment dedicated to a single organisation. This can be on-premises hardware running OpenStack or VMware, or it can be a dedicated section of a public provider's data centre. Banks, healthcare companies, and government agencies often use private clouds to meet compliance requirements.
Private clouds cost more and require more operational expertise. If you don't have a specific compliance reason to use one, you probably don't need one.
Hybrid means running workloads across both public and private clouds. Multi-cloud means using more than one public provider (say, AWS for compute and Google Cloud for machine learning). Both approaches add complexity. They make sense for large organisations managing risk or avoiding vendor lock-in, but for most startups and mid-size teams, they're overkill.
Forget the marketing comparisons. Here's what matters in practice:
Deployment speed. How quickly can you go from a merged pull request to running in production? With IaaS, you're looking at CI/CD pipelines you build yourself. With PaaS, it's usually automatic — push to main, deploy happens. If your team ships multiple times a day, this difference compounds fast.
Operational burden. Every hour spent debugging a Kubernetes cluster is an hour not spent building features. Be honest about your team's size and skills. A two-person startup doesn't need the same infrastructure as a 500-person engineering org.
Cost at scale. PaaS is typically cheaper when you're small (no ops team needed) and can become expensive at very high scale. IaaS is cheaper per unit of compute but requires people to manage it. Run the numbers for your specific workload, not a hypothetical one.
Ecosystem and lock-in. Every provider has proprietary services that work brilliantly but tie you to their platform. Use managed databases and queues freely — they save real time. But keep your application code portable. If your business logic depends on a single provider's API, that's a risk worth acknowledging.
If you're a developer or small team shipping a web application, here's the honest advice: start with PaaS. You can always move to more complex infrastructure later, but you can never get back the weeks you spent configuring load balancers instead of talking to users.
Pick a platform that supports your language, connects to your Git repo, and gets out of your way. Code Capsules was built for exactly this — South African-hosted, Git-connected deployment that handles the infrastructure so you can focus on your code. But whatever you choose, the principle is the same: deploy early, deploy often, and don't over-engineer your infrastructure before you have users who need it.
Cloud deployment isn't complicated. The industry just has a habit of making it sound that way.
