Dev hosting is not a category of product; it is a label that hosts apply to whichever plan they want developers to buy. What a developer actually needs from a host is six specific capabilities: deployment from a Git repository on every push, environment variables set outside the code, build and runtime logs in one place, a rollback to the previous deploy, a managed database on a private network beside the application, and a plan ladder that goes from nearly free to production size without a migration. A host that has those six is a developer host whatever it calls itself. A host that advertises SSH access, a free domain and unlimited bandwidth has listed three things that are either table stakes or not true, and has answered a different question.
This post is a checklist, written for the person evaluating a host for a side project, a client build or a startup’s first service. It names the capabilities, says why each one matters in practice, and lists the features that appear on developer-hosting comparison pages and should carry no weight.
Table of contents
- 1. Deploy from Git, on push
- 2. Environment variables, outside the code
- 3. Logs: build and runtime, same screen
- 4. Rollback to the previous deploy
- 5. A database beside the application, on a private network
- 6. A plan ladder without a migration
- The features that should carry no weight
- Staging, previews and the team
- Reading the price honestly
- How this fits the rest of the stack
- FAQ
1. Deploy from Git, on push
The unit of work is a commit. A host that deploys the repository’s main branch on every push, and builds a preview for every pull request, removes the deployment step from the developer’s day entirely. The alternatives, uploading files over SFTP, running a deploy script from a laptop, or logging into a server to pull, are all ways to have a deploy that depends on whose laptop it ran from.
What to check: does the host connect to the repository and build from it, or does it expect an artefact you built elsewhere. Does it show the build log when the build fails. Does a failed build leave the previous version running, which is the behaviour you want and not every host has.
2. Environment variables, outside the code
Secrets and per-environment settings belong in the host’s configuration, not in the repository. The host should let you set variables per service and per environment, inject them at build time and at runtime as appropriate, and never show them in logs. This is basic, and it is basic because the alternative, a config file with a database password committed to Git, is the most common way small projects leak credentials.
3. Logs: build and runtime, same screen
When a deploy fails, the question is whether the build failed or the process failed after starting. Those are different problems with different fixes, and a host that shows one log but not the other leaves you guessing. The build log should show the install and the compile; the runtime log should show the process’s stdout and stderr, live, with the deploy that produced it. If reading a log means SSH and tail -f, the host is a server, not a platform.
4. Rollback to the previous deploy
A bad deploy at five on a Friday should be a one-click return to the version that was working at four. That requires the host to keep previous builds rather than overwriting them, and to switch traffic back without a rebuild. Rebuilding the previous commit is not a rollback; it is a second deploy that might fail differently.
5. A database beside the application, on a private network
Almost every application needs a relational database, and the host that makes you find one elsewhere has moved the hardest operational task off its own list and onto yours. A managed Postgres or MySQL instance from the same host, with backups, a connection limit stated per plan, and a private network so the database is not reachable from the internet, is the difference between a platform and a place to run a process.
The private network matters more than it sounds. A database with a public address and a password is a database that will be scanned within the hour of creation. One that only the application’s network can reach removes that class of exposure without a firewall rule to maintain.
6. A plan ladder without a migration
Projects start small and some of them grow. The host should have a plan for a prototype at a few dollars a month, a plan for a production service with a few vCPUs and gigabytes of memory, and a way to move between them that is a setting, not a migration. Autoscaling between a floor plan and a ceiling plan, based on CPU, is the version of this that handles a traffic spike without a human. A host whose small plan is a different product from its large plan, with a different control panel and a data transfer between them, has a ladder with a gap in it.
The features that should carry no weight
- Free domain. A domain costs about a coffee a year and is usually free only for the first year of a longer contract. It is a rounding error and a lock-in.
- Unlimited bandwidth or storage. Subject to a fair-use policy that defines the actual limit. A stated allowance with a per-gigabyte overage is more honest and easier to plan around.
- SSH access. Useful on a server you administer. On a platform, it usually means the platform is a server with a control panel, and the six capabilities above are yours to build.
- One-click installers for a hundred applications. You need one application, the one you are writing.
- Uptime guarantees. A 99.9% figure with a service credit is a refund policy, not an architecture. Ask instead what happens to your service when a node fails.
- Developer-friendly, in the plan name. The word is free.
None of these is a reason to reject a host. They are reasons not to choose one, because they say nothing about the six capabilities that decide whether deploying and operating the application is pleasant or a chore.
Staging, previews and the team
Beyond the six, two things separate a host that suits a solo developer from one that suits a team. Preview deployments for pull requests, so a reviewer can open the change at a URL rather than checking out the branch. And team accounts with roles, so the person who can deploy is not the same as the person who can delete the database, and so the credentials do not live in one founder’s password manager. Both become important on the day the second developer joins, and both are hard to bolt on afterwards.
Reading the price honestly
A developer host’s price has three parts: the service plan, the database plan, and bandwidth beyond an included allowance. Storage for uploads is a fourth on some. The number to compare between hosts is the sum for the stack you actually run, not the headline of the smallest plan. Two services and a database on modest plans is a specific figure, and it is the figure that matters, because it is the one that appears on the card every month.
How this fits the rest of the stack
That sum is what the RunxBuild hosting calculator produces: a service deployed from GitHub on a plan with the vCPU and memory printed, a managed database on a private network beside it, storage and bandwidth as separate lines, with the Free tier’s fifteen free days each month and the $4 Dev plan stated as they are. The six capabilities above are the product, from environment variables and logs to rollback and autoscaling between plans, which is what the label dev hosting ought to mean.
Useful related references:
- Free for Dev: What the Free Tiers Actually Cover, and Where They Stop
- GitHub Action for npm Build: Caching, Node Versions, Artifacts, and Deploying the Output
- Best VPS Company: The Criteria That Matter More Than Any Ranking List
- Deploying from GitHub on RunxBuild
FAQ
What is dev hosting?
A marketing label rather than a product category. In practice it should mean a host that deploys from Git on push, manages environment variables, shows build and runtime logs together, supports rollback, provides a managed database on a private network, and offers a plan ladder from prototype to production without migration.
What is the most important feature in hosting for developers?
Deployment from a Git repository on every push, with the build log visible and a failed build leaving the previous version running. It removes the deploy step from daily work and makes the commit the unit of release, which every other capability builds on.
Do developers need SSH access to their host?
Only if the host is a server they administer. On a platform that provides Git deploys, logs, environment variables and rollback, SSH is unnecessary, and its presence on a feature list often signals that the platform is a server with a control panel rather than a managed deployment path.
Should the database be from the same host as the application?
Yes, where possible. A managed Postgres or MySQL from the same host can sit on a private network with the application, unreachable from the internet, with backups and connection limits handled per plan. A database elsewhere means a public endpoint, cross-provider latency and metered bandwidth.
How should I compare hosting prices as a developer?
Add up the service plan, the database plan, storage if needed and bandwidth beyond the included allowance for the stack you actually run. Compare that sum between hosts, not the headline price of the smallest plan, and check that moving to a larger plan later is a setting rather than a migration.