What are the best ways to deploy a Python application and how much do they cost?

Quick answer: common ways to deploy a Python app range from cheapest/simplest to most flexible: a platform-as-a-service like Railway or Render (pay-as-you-go, minimal setup), a managed container service (AWS Fargate, similar per-request/per-hour cost, more control), a full VPS you manage yourself (cheapest at scale, most operational overhead), or serverless functions for spiky, low-traffic workloads (pay only per invocation). The right choice depends more on how much ops work you want to own than on cost alone.

Hi, I'm Neil, your DevOps expert, come and ask me questions. Today's question is: I've got this wonderful Python app deployed and it runs wonderfully on my machine — how can I deploy that to the internet so the rest of the world can enjoy my hard work? Well, here are seven ways to deploy your Python app, and if you stick around to the end there's a cost comparison chart and a little flowchart to help you decide which one is right for you.

We all want smooth deployments, and to get smooth deployments we need a plan, and the plan in code is DevOps — easy, right. We've got our Python app, and we're looking at seven different ways to deploy it to a server, because there's always a server somewhere, even if we're not running it ourselves, for the internet to see our hard work.

1. Bare metal

You can't get any more basic than this — whether it's a Raspberry Pi, or something bigger like a Dell PowerEdge server (I cut my teeth largely on HP servers, or Compaq as they were known before that). Aside from unpacking it, installing the CPUs (they don't come with the CPU installed), and sliding it gently into the rack in the air-conditioned room, you switch it on and you're greeted with a boot screen. What it does mean is you've got full control over the hardware — you know exactly what's going in there, the exact amount of memory and CPU is all available to you, nothing else is going to steal it. Want a graphics card for some CUDA work? Put one in, or several — you know exactly what's in there, full control, it's in your data centre.

The admin is a bit more tricky, though — you get a black, scary boot screen asking for a boot device. Load up a well-known Linux distribution of your choice, Red Hat or Debian-based, stick it on a USB drive, and click through the install. If you've got a lot of these to look after, you might use a golden image with an unattended install file that installs a predefined suite of packages — more admin effort up front, but handy at scale (when I was doing this I was deploying hundreds, even up to a thousand servers by the time I was done).

Once it's booted with an OS on it, we can run Ansible — a configuration management tool that lets us personalize the server. For our Python app, we make sure Python is installed, install a virtual environment and package manager (pip or Poetry), install all the dependencies, install a web server, and then we can get our thing running. Easy peasy — but the start is hard. You do get full control, though.

2. Virtual private server

You've probably seen these — Amazon EC2, Linode, droplets from DigitalOcean. It's a bit like the bare metal server, except you've only got a slice of it, and you don't get that scary boot screen (some providers do give you access to it, but you're in the same situation) — they give you an operating system to start with, so you can SSH into it and off you go. Of course, don't just SSH in manually — use an Ansible playbook like before, which installs Python, patches, a web server (Apache, nginx, Unicorn, or whatever you choose). Again, full access to the operating system, but you're not necessarily in full control of the hardware — you don't know how many other people are sharing the CPU and memory with you, or whether there's a usable graphics card (some VPS providers do offer that option). You get what you pay for — the more you spend, the bigger server you get. Once deployed, you've got your Ansible playbook, happy days, server deployed.

3. Docker containers

Who hasn't heard of Docker containers — very easy to run on your local machine, you've got a Dockerfile, you spin the thing up, five seconds later your Python app is running in a container. Getting that onto the cloud is a different matter — quick to deploy, but a bit trickier to monitor because we don't have access to all the surrounding ecosystem. If you're on a VPS, say two VPSes, each can run Docker Compose, pulling our built Docker image from wherever it lives, which simplifies the VPS or bare-metal setup by removing the need to install lots of dependencies — everything goes in the container, and the only dependency we need on the host is Docker.

We can also use a Compose-like configuration to deploy to a hosted provider — Google Cloud Run lets you provide a configuration for your container and it'll run it on Google's servers for you; likewise AWS provides ECS (Elastic Container Service), where you provide a similar config and it hosts your container happily.

4. Serverless

Why worry about a server at all? It doesn't cost much to run, because you only pay while the function is running — for a web app that's typically a request comes in, we process it, and reply, all in well under a second, so you've paid for that tiny snippet of time, which is cheap if you're not getting much traffic. The downside is scaling cost — if you're getting millions of requests per second, all those little charges add up and can end up costing more than owning the server yourself. You can do this on Google Cloud Run, which lets you write a function hosted on Google Cloud, or on AWS with Lambda, where you upload your code as a zip file and it runs when triggered.

You might think you're getting away without worrying about anything else, but you do need extra infrastructure — AWS gives you API Gateway, which takes in the request, passes it to the function, the function does its thing and replies back to the gateway, which goes back to the customer. So you need this extra piece to trigger your function and handle the request/response, a bit like a web server. It can get more complicated still — the gateway could go to the Lambda, which goes to a VPC endpoint, which goes to a database (I haven't mentioned databases yet — that's another complication altogether, but if your Python app needs storage, you'll need a database at some point; for all the options above, a database is usually an add-on service).

5. Platform as a service

Heroku gives you a very easy way of deploying your application — you give it a git repository, with some special config in there, and it installs it for you and gives you a server address. Happy days, minimal effort on your part. Railway and Render do similar things, both slightly differently, both with simpler payment plans, and as a platform as a service they give you the extra add-ons you want — need a database? Just add it on. More CPU? Just add it on. Costs can scale up quickly, but they scale with you — start very small, end up very large. At the larger end you're probably better off looking at the VPS or bare metal options.

6. Managed Kubernetes

If you've got a lot of microservices to look after — not one app anymore, but 10 or 20 working together — you might need something like a Docker cluster, and one way of doing that is managed Kubernetes (not the only way — I've got another video on Kubernetes alternatives, link below). Touching on the alternatives, there's EKS, GKE, and AKS, depending on whether you're Amazon, Google, or Microsoft flavoured — they're all pretty similar, they all bill slightly differently, and whichever you go with probably makes sense based on where you have the most knowledge, or other services already in that ecosystem. At this level you've probably got a team supporting that decision, and to deploy it you can use Helm charts and other definitions. It costs a significant chunk of money — almost a "stupid tax" — but it provides a lot of functionality on the back end.

7. A hybrid approach

We can combine a couple of these strategies to be really strong. Something running on an EC2 machine gives us a baseline amount of CPU compute, relatively cheap compared to Lambda, and we tie that to Lambda to deal with peaks when we're really busy — mixing the two together gives a blend of a cheap base cost and a slightly more expensive peaky cost, to work with traffic that isn't flat and predictable.

Which one is right for you?

I've attached a decision flowchart below that goes through the questions — do you need full control over the hardware, do you have a support team helping you, do you have multiple containers or just one to look after. Have a look at the flowchart and let me know in the comments if you found it useful. I've also included a cost comparison chart, giving you the upfront basic costs of an average server that can host more than one container, which should give you a clue.

If you want any feedback, ask me a question below, or come along and ask me at my Q&A — there's an invite link at tech-answers.club, I'd look forward to seeing you there. Anything else I can help you with, ask me a question, and I'll see you in the next video.