Moving personal demos from Heroku to Vercel

Earlier this year I moved my personal sites and demos from Heroku to Vercel. Both are services that host web apps for you, so you don't have to run your own servers. The main reason for the move was cost. Heroku had dropped its free tier, and my collection of small apps was costing me more than eighty dollars a month. After the move it came to about fifteen.

The savings were nice, but what I cared about most was that my portfolio kept working. The whole point of these demos is that someone can click a link, land on a working app, and decide whether my work is relevant to what they need. So I wanted to make sure every one of those links still worked after the move.

Making a list first

Before moving anything, I made a list of every project I had deployed. For each one I wrote down its web address, where its code lives, the settings and passwords it needs to run, any database or outside service it depends on, and the page a visitor is most likely to try first.

That last one turned out to matter the most. A site can look like it's up while the page people actually use is broken, for example because a setting didn't get copied over or a redirect points somewhere that no longer exists. Since these demos are often the first thing a potential client sees of my work, I wanted to catch that kind of problem before they did.

The list also showed me that not every project belonged in the same place. Some were simple enough to move straight to Vercel. Others needed a database, relied on an outside service, or had work that needed to keep running in the background, and those needed a bit more thought.

Putting each piece in the right place

Vercel works really well for the public part of my portfolio, which is the web pages themselves plus small bits of server code that run when someone loads a page. It makes putting up a new demo or a new write-up fast.

It isn't a good fit for everything though. Anything that needs to run on a schedule, keep running for a long time, or hold a connection open needs a different home. So now the public sites live on Vercel, and the scheduled work (like the program that collects numbers for my trading dashboard) runs on a small server at home. Only the finished, safe-to-share data gets sent over to the website.

Splitting it up that way has been a lot simpler than trying to make one hosting service do all of it.

Moving the settings along with the code

The code was only part of each move. Each app also depends on settings that live outside the code, like passwords for outside services, custom domain names, and the addresses those services send people back to after they log in or pay.

I learned to treat those settings as a checklist instead of trying to remember them. For each app I checked that the live version had every setting it needed, that nothing secret was exposed to visitors' browsers, and that each outside service knew the app's new address. That last part matters most for logins and payments, because those send the visitor off to another site and back again, and a stale address breaks that round trip.

Clicking through it like a visitor would

Once each app was deployed, I checked the live links myself instead of trusting that the build finished without errors. The check was simple. I opened my portfolio, clicked through to each project, loaded the demo, and tried the main thing it's supposed to do.

That caught a few problems that never showed up in the build logs. It also made me realize that keeping the demos working is part of keeping my portfolio up, since a broken demo reflects on the whole site and not just that one project.

Where it ended up

My hosting bill went from more than eighty dollars a month to about fifteen. I also ended up with one consistent way to put new pages online and a quick routine for checking that everything still works, which has made it a lot easier to keep adding new projects.