Hosting Node.js i Next.js. Wypychasz kod, strona działa.

1. Node.js needs something between PaaS and a bare server

For a Node.js application, a natural first choice is often the model used by PaaS (Platform as a Service) platforms: git push and the application runs, without having to manage a server. The problem starts with the bill: most of these platforms charge in dollars, and with real production traffic, prices quickly add up, while the infrastructure is physically located outside Poland.

On Saplo, a Node.js app starts with a ready-made Express starter. Choose Node version 18, 20, or 22, with 20 as the default, then replace the starter with your own code through Git deploy. A push to the repository automatically updates the running app, so you do not need to log in to the server after every change.

The app manifest declares a minimum of 512 MB RAM and 3 GB of storage, which means even Box S (1 GB RAM) can technically run a simple Node.js app. For anything beyond a prototype, however, consider Box M with full SSH access.

2. Git deploy vs. manual upload

Git deploy makes your code repository the single source of truth for what runs in production: a push to a designated branch triggers an app update on Box, with no manual FTP uploads or SSH copying after every code change.

For a team of developers working on the same Node.js app, this makes a real difference: every commit pushed to the right branch goes straight to the server, enabling fast iteration with no deployment steps beyond git push.

Box M's SSH access with sudo also gives you manual control over the Node.js process, including restarting it after environment variable changes or installing additional system packages required by some npm dependencies. You cannot always do this through git deploy alone.

3. Why not a classic VPS?

On a bare VPS at Competitor A (1 vCPU, 2 GB RAM, 20 GB of storage for $12/month net, public price list, as of 2026-10-10), deploying a Node.js application requires installing Node, a process manager (e.g. PM2), a reverse proxy and an SSL certificate yourself before the application is publicly available on an HTTPS-enabled domain.

On Saplo, these components, including an nginx reverse proxy, SSL, and a process manager in a container, are configured automatically when you install from the catalog. It takes only minutes to go from choosing a Node version to a running, publicly available app on your own domain, instead of spending hours configuring the server manually.

The cost is comparable to a VPS with similar resources, but you do not have to administer the operating system or worry that a firewall configuration error or system update could take the app offline for reasons unrelated to the Node.js code itself.

4. Multiple Node.js apps on one Box

With no limit on the number of apps per Box, you can run multiple independent Node.js projects at the same time, such as an API, an admin panel, or an independent microservice. Each runs in its own LXC container with its own domain or subdomain, with no port conflicts between projects.

For apps that use a database, you can add separate database modules (Postgres, MySQL, or Redis) as containers in their own Docker Compose file, not as paid add-ons. A typical Node.js and database stack works together naturally with no additional cost for the database itself. Adding a database as another app on the same Box takes no longer than deploying it from the catalog, and you do not need a separate contract with an external cloud database provider.

5. Who it is for

For a developer building a simple backend API or microservice, Box M with full SSH access and git deploy provides a fast production environment without configuring a server from scratch.

For a startup developing several Node.js services at once, such as an API, dashboard, and worker, Box L lets you run them all under one account in separate containers, without separate PaaS bills from multiple providers.

For someone migrating from an overseas PaaS platform billed in dollars, Saplo offers a similar deployment experience (git push), but with PLN billing and infrastructure in a European data center.

6. Your first Node.js deployment on Saplo

After deploying the Express starter with your chosen Node version (18, 20, or 22), connect a Git repository in the dashboard so future code changes are deployed automatically whenever you push to the designated branch.

Replace the starter code with your app, but preserve the port configuration and environment variables required by the Saplo engine so the reverse proxy continues routing traffic correctly to your app on the connected domain.

You set environment variables (API keys, a database connection string) in the application panel, without storing them directly in the code repository. This is a security best practice regardless of where the application is hosted.

If your app uses a database, add a separate module (Postgres, MySQL, or Redis) on the same Box and connect to it through an internal address, without exposing the database to the public internet.

Monitor application logs over SSH, available starting with Box M, to catch errors quickly after each deployment before users notice them.

7. Node.js microservices on one Box

Several independent Node.js services, such as an API, a queue worker, and an admin panel, can run as separate apps on the same Box. Each runs in its own container, and they can communicate over an internal network or through public APIs.

This setup makes it easy to deploy each service independently, since a git push to one service does not redeploy the others. As a project grows, this is more convenient than running everything in one large monolithic Node.js process.

Redis as a separate database module on the same Box often serves as a task queue or cache between microservices, with no need to connect to an external paid Redis service outside the Saplo infrastructure.

For a microservice architecture, consider Box L or higher. Several independent Node.js processes, a database, and Redis use more memory than a single simple app.

8. Monitoring and logs for a production Node.js app

Eventually, a production Node.js app will hit an error that did not appear during local testing. SSH access, available starting with Box M, makes process logs a fundamental diagnostic tool, letting you see exactly what happened during an outage or unexpected behavior.

Use structured logging, such as JSON entries with a severity level and timestamp, instead of scattering simple console.log calls throughout the code. This makes it easier to filter logs by event type or error level later, especially as the app grows and produces more logs.

Configure automatic restarts after a crash, such as an unhandled exception that stops Node.js, through the process manager running in the container. This ensures a brief failure does not cause prolonged downtime before someone on the team notices the issue and responds manually.

For apps with many npm dependencies, regularly check packages for known security vulnerabilities using standard npm audit tools. Outdated dependencies are a common attack vector for Node.js apps, regardless of how well the application code is written.

Monitoring the Node.js process's RAM usage over time helps you detect memory leaks before they bring down the entire app. This is a real risk for long-running processes such as WebSocket servers or apps with long-lived connections, especially without proper monitoring. Regularly checking the memory usage trend, even without advanced profiling tools, reveals a growing problem early enough to plan a fix before it causes a production outage.

The Saplo dashboard shows the container's current resource usage, making it the first reference point for diagnosing performance issues before you need more detailed Node.js application profiling tools.

9. The npm community and ecosystem as part of your stack choice

Node.js has one of the largest package ecosystems (npm) among popular languages and platforms. Most common needs, such as authentication, database connectivity, and file handling, have ready-made, proven libraries, so you do not have to write that logic from scratch for every new project.

The full ecosystem is available on Saplo because your application runs in a standard Node.js environment with access to the npm registry, without the platform-imposed restrictions you may encounter on some closed PaaS platforms that support only a limited list of packages.

When choosing between popular frameworks built on Node.js (Express, Fastify, NestJS), the choice is entirely yours. The Express starter provided by Saplo is a starting point you can replace, not a rigid constraint if your project needs a different framework.

Updates to the Node.js environment itself, such as moving to a newer LTS version, are available as an option when you reconfigure the app. This lets you keep up with the Node.js release cycle without migrating to another provider simply because the required environment version has changed.

For teams following the evolution of the JavaScript ecosystem, including new build tools and architectural patterns, full SSH access and a standard Node.js environment on Saplo impose no additional restrictions compared with a traditional, self-managed server.

10. Testing a Node.js application before production deployment

Before every production deployment, test the new version of your app in an environment close to production, for example as a separate temporary app on the same Box, before pushing the change to the live domain your customers use.

Automated tests (unit and integration) run before deployment, even in a simple repository-level CI pipeline, help catch code regressions before they reach the production server through git deploy. This is significantly cheaper than fixing a bug after users can see it.

For apps with critical production traffic, consider deploying changes outside peak traffic hours. This limits the number of users affected by a potential short-lived error during the git deploy code update process.

Rolling back to the previous working version of your code (returning to an earlier commit and pushing it again) is a straightforward safety mechanism if a new deployment causes problems. A Box backup (available from Box L) also protects the application's database in case of more serious issues.

11. Summary: Node.js with git deploy as a fast path to production

Combining the ready-made Express starter, a selectable Node.js version, and automated deployment through git push reduces the time from idea to a running, publicly accessible Node.js app to minutes instead of the hours required to manually configure a server, firewall, and reverse proxy. On a bare VPS, you would have to complete that setup yourself before the first line of application code could run on a production URL with an active SSL certificate. For a developer testing a new idea, this difference in startup time can be decisive. It lets you spend the first hours on application logic rather than configuring the infrastructure that will support it. The advantage is even greater when testing several ideas in parallel, because the cost of validating each new idea is reduced to the time required to write the code, without repeating the same server setup for every attempt.