From VPS to PaaS: Why I Moved Away from AWS Lightsail

Posted by Neil Ludlow on Monday, 29th September 2025

Time to read: 10 minutes

The Problem

I write software for clients, but at any time I also have some personal projects out there. These projects may be websites or apps. Some projects are built in React or another front-end framework, and there are some apps, but even front-end and apps need some kind of API which has to be hosted somewhere. Because they are just my personal projects they have to be hosted relatively cheaply, in this case it's on AWS Lightsail.

What would happen is that I'd try to update the software of the personal projects every so often, but I'd forget, then I only notice something is wrong when I notice the website or app isn't responding. So then, I would do some maintenance on the server to get it up-to-date and working again. Or, as was the case recently, the instances themselves were so old that the operating systems no longer received updates and no longer worked properly. The way to get them to start working again would have been to upgrade the operating systems of those instances, or move them to a new instance.

Upgrading the operating system of an instance "in-place" is risky and can be problematic. While if the upgrade of the operating system goes well, it can take a couple of minutes and everything is fine, if there are problems they may be tricky to overcome. While the upgrade is happening, the website or API will be completely down, so any issues with getting this done can be very stressful. It's generally a lot safer to leave the old instance alone, and spin up a new instance with the up-to-date operating system on it and migrate everything across.

The two challenges here are cost (must be as cheap as possible) and time (must be quick and easy to maintain).

Caveats

This article is talking about this specific circumstance. We need "compute", so we can't use cheaper "blob storage" like AWS S3, and we don't want to pay top dollar for an all-singing all-dancing production solution. By "compute" I mean an environment where code, you could say backend code, is run on the server like a VPS or a PaaS.

Production versions of software should not be hosted on AWS Lightsail. The discussion would have been slightly different if we were talking about a production-grade AWS EC2 instance compared to a modern managed service (a PaaS). Also, hosting my little hobby projects would be a different discussion to talking about hosting enterprise software that has many users, or will have many users.

With EC2 there are different ways to get maximum uptime. Using Elastic Beanstalk with a Code pipeline would be one way to get an automated deployment process and 100% uptime, but there are others.

What Options Exist for Hosting small APIs?

So, we're talking about hosting small APIs, hobby projects and prototypes...

Option 1: Virtual Private Servers (VPS)

Such as: Lightsail / EC2 / Linode /Digital Ocean

A VPS is just like having your own computer or server on the internet. If you were to have your own physical machine plugged into the internet at the hosting company's data center, that would be called a Dedicated Server and that would be relatively expensive. A VPS is the company separating out a certain amount of RAM and storage space and virtual processors that only you can use, so it behaves in a similar way to a dedicated server, but there may be several VPS on each box. Or, in the cloud, you can easily scale and expand your instances, quickly making new instances, and shutting down others. This would be something like AWS EC2, or any hosting company will offer different products but the vast majority will have some kind of VPS. Lightsail is a simplified and cheaper equivalent to EC2 in the AWS ecosystem.

With any VPS, a new instance just comes with an operating system running on it. There are instructions on how to connect to it pretty simply but anything you want to do with it must be done by yourself.

Option 2: Platform as a Service (PaaS)

Such as: Render / Vercel / Railway / Fly.io

Whereas a VPS is like a virtual computer in the sky, a PaaS is the same thing but instead of having to maintain the software you just link it to your code on a source control repository like GitHub, or BitBucket. That's it! You don't have to be aware of the operating system it is running, or anything like that.

When deploying, your deployments are tied directly to your development workflow - when you push to the git repository, your app updates automatically. What happens is you make the code how you want it, then when you're ready you update the code on GitHub. The PaaS is watching the code on the repository, sees when it changes and immediately starts re-deploying. The re-deploy includes installing everything that needs installing and starting the process running. If anything goes wrong with the deploy, in some situations it can just revert to the previous, working version.

Option 3: Backend as a Service (BaaS)

Such as: Firebase / Supabase

Unlike a PaaS, where you still write and deploy your own backend code, a BaaS gives you ready-made services (auth, database, storage) so you may not need a backend at all. This can be great to get set up with a prototype or small hobby project quickly.

As with everything, there are pros and cons to this way of working. It is quite a different way of using an API, out of the box, with a very simple setup you may be quite limited as to what you can do, but like any cloud provider there are many different products you can add on. But, starting off this way means that you are effectively tied to using the service, changing providers would be a headache. Likewise, if you have written all your own code already, switching to a Baas would require extra work.

In Simple Terms

If this still sounds abstract, here is a quick analogy...

VPS - "bare plot of land" - you build the house yourself.

PaaS - "apartment with utilities" - you move in with your own furniture and appliances (code), but don't worry about the plumbing (infrastructure).

BaaS - "ready-made kitchen" - you just start living.

The Thought Process

From having an API that wasn't working on a VPS, what is the best way for me to proceed?

In my situation, I had two options as migrating to a BaaS wasn't an option.

I could...

• upgrade the operating system, that may well have taken a few minutes and been very easy, or it may have taken longer.
• move to a PaaS, this equally would be quite quick and easy.

So, which one to choose?

I know that either way will work. For my purposes, I'm not worried about performance, all I care about is cost and uptime without me having to do anything. Both options are a very similar cost.

So then, one way needs either maintaining manually or setting up to automatically update with some kind of mechanism to inform me if anything breaks in the update process. The other way I don't need to do any maintenance at all, it is all done for me.

Control vs. Convenience

This migration really boils down to the classic trade-off: do-it-yourself vs. done-for-you.

Here's how I see the pros and cons:

VPS

Pros:

• Full control over the environment
• Great for learning and experimenting
• Flexible - you can run almost anything

Cons:

• More maintenance overhead
• Higher risk of downtime if something breaks
• Deployment processes can be clunky unless you build them yourself

PaaS

Pros:

• Minimal setup, everything just works
• Automatic Git deployments
• Built-in SSL, scaling, and monitoring

Cons:

• Less control over the server environment
• Limited customization compared to rolling your own
• Potentially higher costs at scale

Neither option is “better” across the board - it depends on what matters most for your project.

Other Factors

The Database

The move was even easier than it might have been due to the databases being completely separate. It is possible to use AWS Lightsail for the hosting and the database. With these projects the database had already been separated out into separate "database as a service" platforms, such as MongoDB and Neon. Had the database been on Lightsail, the pendulum might have swung more towards staying with Lightsail.

Keeping databases separate from "compute" is a good practice anyway, since it makes migrations like this one easier. At one stage, I remember the database actually being on the same "compute" hosting as the code. In that situation, you actually have to manually maintain the database itself. At least these days there are managed database instances, whether on Lightsail or elsewhere, that do not have to be maintained and are completely separate to the code.

The database discussion around this topic could be it's own article.

Hidden Costs

When I say, the VPS options are often cheaper, or that PaaS options are not much more expensive, that should be put into perspective. The extra time to think about and maintain the VPS is technically a hidden cost, and it is the cost of my time which is arguably more than the potential savings involved. It's not just the time to do the maintenance - it's also the mental overhead of remembering to check everything and keep things patched and secure.

The Solution

What I ended up doing was moving a couple of my APIs from AWS Lightsail over to Render.

Discussion

My Situation

This move wasn't made lightly. I've been running websites and APIs on Lightsail for years and I like the flexibility it offers. But getting to the point where I had to either upgrade the instance or migrate to a newer version forces you to make a decision. And, I should also say, the reason I had to make this decision was that the projects were not working. Because I wasn't working on the projects every day, or even viewing them that often, my apps or APIs would sometimes just stop responding, and it might take me several days, or even weeks, to notice.

Maintenance is a routine part of managing servers. These kind of projects needed to be mostly online, but without me having to think about them every day. I did not want to be distracted from other work, by having to remember to login to upgrade one or more of these instances.

What I could have done was to write a bash script to update the instances frequently, and then tell it to send me an email, or slack message, every morning with the health, or not, of each website. That in itself is not a completely crazy suggestion, I've done this kind of thing in the past. But, it's spending time building something that will put more of my attention into something that I want to forget about until I'm ready to work on it. I'm not a DevOps engineer or Linux Administrator, I make websites, apps and APIs.

Rather than double down on maintaining servers manually, and occasionally having them break, I decided to try something different. Moving them to a modern managed service would reduce downtime and simplifying deployments without adding much cost.

Change

AWS Lightsail had been the right solution for me for a while. If it hadn't been the optimum solution, it was the one that I'd gone with and was happy with. Using Lightsail allowed me to use these hobby projects as experience with networking, system administration, and debugging.

Pivoting when it is right to do so is very important to me. Perhaps, in the past, I have not pivoted quickly enough, I have stayed too long with outdated technology. It is important to me that I attempt to recognise and change where necessary, especially if it is trying something new for my own projects in order to test the waters for larger client projects down the line.

You could definitely make the case that I should have moved these sites across sooner, i.e. before they broke.

I have a few AWS Lightsail instances still running. Those instances will still need regular maintenance, so it's made me want to look at those and start to think about the possible options for where they should live. Maybe that place is Lightsail, or somewhere else.

Future Thinking

Switching between VPS and PaaS is easy. BaaS is more difficult to move away from.

Final Thoughts

While I'm discussing why I have moved some services away from AWS Lightsail, using a VPS is still a valid option.

A VPS might be the best option where:

• more control is a nice thing to have
• you want to learn something new
• if you're mimicking a larger production server but with lower cost
• it might just be cheaper than the alternative service

There might also be other products, other than just standard "compute" hosting that can be better for specific uses. Depending on what it is you want to do, AWS Lambda can be better or cheaper for particular use cases. Or, if you don't need "compute" at all, there are cheaper options that have no "compute" capability such as Azure's blob storage or AWS S3. But for smaller projects that require uptime and "compute", Render, or similar services can be very easy and affordable.

If you've ever found yourself stuck maintaining a server when you'd rather be coding, I'd recommend giving managed platforms (PaaS) a try. You might find, like I did, that the trade-off is more than worth it. Also, it's a part of constantly learning and trying new things to see what works and what doesn't. What functions the way you want it to, and what doesn't.

Conclusion

Always ask: am I doing the right thing with a particular software. What was right yesterday, may not be what's right today, or tomorrow. Flexibility and willingness to pivot are key.