If you want less server work, first decide which jobs the host should take over and which app controls you need to keep. Patching the operating system, releasing the app and restoring the database need different kinds of help.
A managed app platform can take on much of the server work while you look after the code and its dependencies. Shared hosting gives you a ready-made setup with fewer system choices. A virtual-machine platform may make the app easier to deploy while still leaving you with more choices about how to run it.
Choose based on the work you want to stop doing and the controls your app still needs.
1. Render for managed application releases
Render suits a developer who wants to work with the app’s code instead of maintaining the server stack. It supports native Node deployment and Docker. You can release from Git, preview changes and use private networking. Workers and private services let you keep background work separate from the web app.
The smallest paid web compute option costs $7 a month and provides 512 MB of memory. A Hobby workspace has no monthly fee, though you pay for compute separately. The free web option idles after 15 minutes and can take about a minute to wake. That wait may not suit a live service that needs to respond at all times.
The database you choose affects how much work you stop doing. Render offers managed PostgreSQL. For MySQL, you run a Docker private service with a persistent disk. You still need to provide the tools to back up the database.
Check what work you will still do after you deploy. You need to update dependencies, choose the right settings and find the cause of app errors. Letting the platform handle the server helps most when you already know how you will release the app.
If your current server runs MySQL, decide whether you want to keep operating that database. Moving the web process to a managed platform removes only part of the work. A separate managed MySQL service may be a better fit if database work is why you want to leave a VPS.
2. Railway for connected application services
Railway can help if you want to keep the web service and datastore together without managing a VPS operating system. It supports GitHub, Docker images and custom Dockerfiles. You can also use the command line to deploy from a local repository.
Its MySQL template provides a single database node that Railway maintains. You still need to decide on backups and high availability. Set aside time for those choices even if the app is quick to deploy.
Hobby costs at least $5 a month, including $5 of resource usage. Memory, processor use, storage and transfer can take the bill above that minimum. The web service and database each use resources. Estimate the cost of both, then compare it with the server bill you pay now.
This can suit you if you want less time spent maintaining services and can track a bill based on use. Choose enough storage to leave room for the database to grow. Set a routine to check the bill and make sure backups are working.
3. Fly.io when you still need machine control
Consider Fly.io if you want an easier way to deploy the app and choose where it runs. Its command-line tools can create a Dockerfile for common Node frameworks, and you can deploy from GitHub. You choose how to put Machines, volumes and private networking together for the app.
It leaves you more choices about how things run than the managed app options here. You still decide how the machines and persistent storage fit together. If you run MySQL yourself, you also need to maintain it. The managed database product is PostgreSQL.
A displayed regional example starts at $2.19 a month for a shared-cpu-1x Machine with 256 MB. That does not show whether the app will fit, and it excludes the database and other resources. Volumes cost $0.15 per GB-month, with external transfer priced separately.
Use Fly.io when the app needs that extra control. If you want the host to make nearly every database and machine choice, first compare hosts that manage both the app and database. Include paid support in the cost if you need it.
4. Heroku for a defined application process model
Heroku patches the operating system and manages the app platform as part of the service. It supports Node through its language tools. You can deploy with Git or Docker, see app logs and have it manage certificates.
The Basic dyno costs $7 a month for 0.5 GB of memory and stays on. Eco costs $5, sleeps after 30 minutes without activity and is limited to personal accounts. Start with Basic if the service needs to respond throughout the day.
The database remains a separate service. Heroku provides managed PostgreSQL, while a MySQL project can use a third-party add-on such as JawsDB. Check how that supplier runs and restores the database separately from the dyno plan.
App files also need a storage plan. A dyno’s temporary filesystem should not be the only place you keep data that must last. Before moving from a VPS, check which files the app writes and decide where they will go. Heroku handles server upkeep, but the app needs to follow the way its platform works.
5. GreenGeeks for a ready-made shared environment
GreenGeeks provides a cPanel-managed Node environment on Pro and Premium. You get Git, SSH, startup settings and environment variables. The account includes a MariaDB database for apps that can use it. This can suit you if you want to run a small service within an existing hosting setup.
The Pro introductory rate is a $4.95 monthly equivalent with 12 months prepaid. It renews at an $18.95 monthly equivalent. Lite does not include the Node runtime.
The company manages the hosting system. You handle the app code and dependencies and set up the app. Support does not cover debugging Node apps or helping deploy them. The managed server service will not fix an error in your code.
Check which system tools the app needs before moving. The shared account has no root or Docker access. Having Git does not mean a push deploys the app on its own. This option fits if the ready-made setup meets the app’s needs and you can manage its releases yourself.
6. Sevalla for managed hosting and database choices
Sevalla lets you deploy from source code or a container without maintaining the server beneath it. It accepts GitHub, GitLab and Bitbucket sources, Dockerfiles, buildpacks and registry images. Pull-request previews let you check a change before it reaches the live app.
You can buy managed MySQL, MariaDB and PostgreSQL separately from the app. The service backs up the database each day and supports private network connections. These can remove database-server jobs you might otherwise still need to do after leaving a VPS.
Start the cost comparison with the hostname you need. H1 costs $5 a month but excludes custom domains. S1 costs $10 for 0.5 CPU and 1 GB of memory. Add the selected database, builds and external bandwidth to the application rate.
The smallest database costs $5 a month with 1 GB of storage. Check whether that allowance fits the current database and its growth. A managed service can reduce your work. You still need to choose enough resources and check that the backups let you restore the app as needed.
7. Northflank for applications with workers and jobs
Northflank can suit you if you want one platform to manage several parts of the app. It supports web services, workers, jobs and a managed MySQL add-on. Git sources, buildpacks, Dockerfiles and registry images provide several deployment paths.
The Sandbox offers limited always-on services, jobs and a database for tests. Paid compute is billed by the second, with storage and network charges added. Budget for the web service, worker and database as separate resources.
You still make some choices about the database. Northflank provides backup and restore tools. You set when backups run and how long to keep them. High availability needs more database resources, which you must set up.
This reduces the need to maintain the server beneath each part of the app. It is useful if the app already needs to keep background work separate. Decide who looks after service settings and secrets so everyone knows which app jobs still belong to you.
Who restores the app and database?
Before you cancel the VPS, write down who can restore the service. Say who can restore the database, redeploy the app and connect it to the restored data. Include the access each person needs. Make sure the backup does not depend on one person who may be unable to get to their account.
Set a clear goal for restoring the service. Decide how much recent data the app can afford to lose and how long it can be down. Then check whether your chosen backup schedule and restore process can meet that goal.
Make sure the restore guide covers the whole request path. You may need to change the app’s connection settings after restoring the database. Someone should check those settings and test normal reads and writes before traffic returns.
Test the restore in a separate environment and record what it takes. Keep the code, needed settings and backup access outside the running service, where you can still reach them. The move has reduced your server work when you can manage the tasks that remain and know who will do them.
Leave a Comment