DEV Community: Arthur

When Does a Website Need VPS Hosting?

Arthur — Sun, 18 Oct 2026 08:04:23 +0000

Many websites start with basic hosting, and that is completely fine. If you are running a small blog or a simple website, you may not need advanced server resources at the beginning.

But as your website grows, you might start noticing slow loading times, limited resources, or less control over your hosting environment.

1. When Basic Hosting Is No Longer Enough

Shared hosting is a good starting point for beginners. However, multiple websites share the same server resources, which can sometimes affect performance.

If your website receives more visitors or runs resource-heavy applications, you may need a more flexible hosting solution.

2. What Makes VPS Hosting Different?

A Virtual Private Server (VPS) provides dedicated resources within a virtualized server environment. It usually gives you more control over server settings, software installation, and resource management.

VPS hosting can be useful for:

Growing business websites
Web applications and APIs
Development and testing environments
Websites that need more control over server configurations

3. Check Your Requirements Before Choosing

Before switching to VPS hosting, consider your expected traffic, RAM requirements, storage, bandwidth, and technical experience.

For example, a small website may work well with a basic VPS, while a larger application might require additional CPU cores and memory.

You can explore HelloServer VPS hosting to learn more about available hosting options and compare them with your project's requirements.

4. Is VPS Hosting Right for Everyone?

Not necessarily. If your website is small and your current hosting performs well, there may be no reason to upgrade immediately.

However, if you need more control, predictable resources, or room to grow, VPS hosting is worth considering.

The best approach is to identify your current limitations first and choose a hosting plan that matches your actual needs.

Final Thoughts

Choosing hosting is not just about getting more resources. It is about finding the right balance between performance, control, reliability, and cost. Start with your website's current needs and upgrade when there is a clear reason to do so.

What Happens When a Web Server Runs Out of Memory?

Arthur — Fri, 16 Oct 2026 14:08:46 +0000

Hello, I’m Arthur. When working with websites and applications, we usually focus on features, design, and performance. But there is one problem that can affect everything: a server running out of memory.

I wanted to understand why applications sometimes become slow or stop responding, even when the server seems to be working normally. Memory usage is one of the things worth checking.

Why Does a Server Need RAM?

RAM stores the data and instructions that running applications need to access quickly. A web server uses memory for processes, active connections, application code, caching, and other tasks.

When several applications run at the same time, memory consumption can increase. A busy database, a memory leak, or too many application workers can put additional pressure on the system.

What Happens When RAM Is Almost Full?

When a Linux server runs low on available memory, several things can happen:

Applications may respond more slowly.
The operating system may reclaim cached memory.
Swap space may be used, which is generally slower than RAM.
Under severe memory pressure, the Linux Out-Of-Memory (OOM) killer may terminate processes to protect the system.

This is why high memory usage deserves attention, especially on production servers.

How to Check Memory Usage in Linux

You don't always need advanced monitoring software to start investigating a memory problem.

The free -h command displays memory usage in a readable format:

free -h

To inspect running processes and their resource consumption, use:

top

You can also review system logs for memory-related events. On systems using systemd, this command may help:

journalctl -k

Depending on your permissions and system configuration, you may need elevated privileges to access some kernel logs.

Remember that Linux uses available memory for caching, so high memory usage alone does not necessarily mean something is wrong. Pay attention to available memory, swap activity, application behavior, and system logs together.

How Can You Prevent Memory Problems?

A few practical habits can make server management easier.

Monitor resource usage: Track memory consumption and set alerts for sustained pressure rather than reacting to a single reading.

Investigate application behavior: Look for memory leaks, unnecessary processes, and workloads that consume more RAM than expected.

Optimize configuration: Review application worker counts, database settings, and caching strategies.

Choose suitable resources: Make sure your server has enough memory for its expected workload, including periods of higher traffic.

Test before making changes: Avoid restarting services or changing production settings without understanding the cause of the problem.

Does VPS Hosting Make a Difference?

A Virtual Private Server provides allocated virtual resources, including RAM, according to the selected plan. This can give developers more control over their environment and application configuration.

However, a VPS cannot automatically prevent memory problems. The required resources depend on the software, traffic, database workload, and background processes running on the server.

If you're exploring hosting options for development or production projects, you can learn more about HelloServer and its hosting services.

Final Thoughts

Memory problems are easier to handle when you understand what the operating system is doing. Checking memory usage, investigating processes, and reviewing logs can help you identify the real cause instead of making random configuration changes.

You don't need to be an experienced system administrator to start learning these skills. A few basic Linux commands and a habit of monitoring your server can take you a long way.

How to Back Up Postgres on a VPS (and Prove the Restore Works)

Arthur — Wed, 14 Oct 2026 16:27:52 +0000

Hi, I'm Arthur. Picture this: a migration meant for staging runs against production, and a table is gone. You open your backup folder and find a file from three weeks ago, or nothing at all because the cron job has been failing quietly since a disk filled up.

Most "back up Postgres" guides stop at one pg_dump command. That's the easy part. What saves you is knowing the job ran, having a copy that isn't on the same disk, and having restored it at least once. This guide builds all three on a single Ubuntu VPS.

What you need

A VPS running Ubuntu with Postgres installed and root access. HelloServer offers VPS plans with full root access, and any similar provider works the same way.
Somewhere off the server to store copies: any S3-compatible bucket, Backblaze B2, or similar.
About 30 minutes.

Why `pg_dump` and not a file copy

Copying Postgres's data directory while it's running can give you files that don't match each other. pg_dump takes a consistent snapshot of the database without blocking writers. The -Fc (custom) format also compresses the dump and lets you restore single tables with pg_restore.

Step 1: A place for backups

sudo mkdir -p /var/backups/postgres
sudo chown postgres:postgres /var/backups/postgres
sudo chmod 700 /var/backups/postgres

Only the postgres user can read it. A dump contains all your data, so treat the folder like the database itself.

Step 2: Set up offsite storage

Install rclone and configure a remote as the postgres user, so the cron job can find the config later:

sudo apt install -y rclone
sudo -u postgres rclone config

Follow the prompts to add your storage provider and name the remote remote. Then check it works:

sudo -u postgres rclone lsd remote:

Dumps leave your server here, so encrypt them. rclone has a crypt remote type that wraps another remote: create one pointing at remote:my-backups and use it in the script below instead of the plain one.

Step 3: The script

Save this as /usr/local/bin/pg-backup.sh:

#!/usr/bin/env bash
set -euo pipefail

DB="myapp"
DIR="/var/backups/postgres"
STAMP="$(date +%F_%H%M)"
FILE="$DIR/${DB}_${STAMP}.dump"

# 1. Dump to a temp file first, so a half-written file never looks valid
pg_dump -Fc "$DB" > "$FILE.tmp"
test -s "$FILE.tmp"
mv "$FILE.tmp" "$FILE"

# 2. Roles and passwords live outside any single database
pg_dumpall --globals-only > "$DIR/globals_${STAMP}.sql"

# 3. Copy offsite
rclone copy "$FILE" remote:my-backups/postgres/
rclone copy "$DIR/globals_${STAMP}.sql" remote:my-backups/postgres/

# 4. Prune: 7 days locally, 30 days offsite
find "$DIR" -type f \( -name '*.dump' -o -name 'globals_*.sql' \) -mtime +7 -delete
rclone delete remote:my-backups/postgres/ --min-age 30d

# 5. Tell the monitor we finished
curl -fsS -m 10 --retry 3 https://hc-ping.com/YOUR-UUID-HERE > /dev/null

A few details are worth understanding before you copy it:

set -euo pipefail stops the script at the first failure. That matters because step 5 only runs if everything before it worked.
pg_dumpall --globals-only saves roles and their passwords. Without it, a restore onto a fresh server fails because the app's database user doesn't exist.
The pruning lines keep the folder and bucket from growing forever. Disks that fill up are one of the most common reasons backup jobs stop.

Make it executable and run it once by hand:

sudo chmod +x /usr/local/bin/pg-backup.sh
sudo -u postgres /usr/local/bin/pg-backup.sh
ls -lh /var/backups/postgres

Check that the file has a real size and that it also appears in your bucket.

Step 4: Schedule it and get alerted when it fails

Add a cron job for the postgres user:

sudo crontab -u postgres -e

15 3 * * * /usr/local/bin/pg-backup.sh >> /var/backups/postgres/backup.log 2>&1

That runs at 03:15 every night. Now the monitoring: a service like Healthchecks.io gives you a unique ping URL and emails you if no ping arrives on schedule. Paste that URL into step 5 of the script. This catches the failure cron never reports: the job that silently stopped running. Set the expected period to one day, with a grace period of an hour or two.

Step 5: The restore drill

This is the step that turns a file into a backup. Restore into a scratch database, not your live one:

sudo -u postgres createdb myapp_restore_test
sudo -u postgres pg_restore -d myapp_restore_test --no-owner \
  /var/backups/postgres/myapp_2026-10-14_0315.dump
sudo -u postgres psql myapp_restore_test -c "SELECT count(*) FROM users;"
sudo -u postgres dropdb myapp_restore_test

Compare the row count with production. Note how long the restore took, since that's your real downtime in an emergency.

A full rebuild on a brand-new server goes in this order: install Postgres (same major version or newer), restore the globals with sudo -u postgres psql -f globals_....sql, then createdb and pg_restore the dump. Do this drill once now, not for the first time during an outage.

If Postgres runs in Docker

Run the dump through docker exec, but don't add -t:

docker exec db pg_dump -U postgres -Fc myapp > myapp.dump

The -t flag allocates a terminal, which can corrupt binary output, and you won't notice until you try to restore.

Where this setup falls short

You can lose up to a day of data. A nightly dump only captures that moment. If that's too much, look at continuous archiving with a tool like pgBackRest or WAL-G for point-in-time recovery.
Big databases slow down while dumping. It doesn't block writes, but it uses CPU and disk. Schedule it for your quietest hour.
Same provider is still a single risk. For a second layer, a small separate VPS can act as a backup target over SSH with rsync. A second small plan from HelloServer would work for that.

Your checklist

Run the script once by hand and check the file size.
Confirm the copy landed in your bucket.
Set up the monitor and let it alert you once, on purpose, by skipping a run.
Do the restore drill and write down how long it took.
Put a reminder on your calendar to repeat step 4 every few months.

If you want a safe place to try this end to end, a small VPS from HelloServer is enough, because you can break things and rebuild without touching a real project. How often do you actually test your restores? I'd like to know whether anyone does it on a schedule.

Why Developers Need Reliable VPS Hosting for Modern Applications

Arthur — Mon, 12 Oct 2026 15:44:41 +0000

Modern applications need more than good code. They also need reliable infrastructure, stable performance, and enough resources to handle real-world workloads.

Whether you're deploying APIs, running Docker containers, hosting websites, or managing databases, choosing the right server can make a big difference.

1. Why Infrastructure Matters

An application may work perfectly in a local development environment but behave differently in production. Limited RAM, CPU bottlenecks, slow storage, and network issues can all affect performance.

Before deploying an application, consider:

CPU: Choose enough cores for your application's workload.
RAM: Leave sufficient memory for your application, database, and background processes.
Storage: NVMe SSDs can improve disk-intensive workloads.
Network: Reliable bandwidth matters for APIs, downloads, and distributed services.
Scalability: Make sure you can upgrade resources as traffic grows.

2. VPS vs. Shared Hosting

Shared hosting can work well for small websites, but developers often need more control over their environments.

A Virtual Private Server (VPS) provides dedicated virtualized resources and greater control over software, services, and configurations. It can be useful for staging environments, web applications, APIs, and development projects.

However, the right choice depends on your workload, budget, and management requirements.

3. What to Check Before Renting a VPS

Don't choose a server based on CPU cores alone. Review the full configuration and ask:

How much RAM and storage are included?
Is the storage NVMe or SATA SSD?
What network speed and traffic limits apply?
Which operating systems are supported?
Is technical support available?
Can resources be upgraded later?

For developers comparing server options, HelloServer VPS hosting is one option to explore alongside other providers.

4. Monitor Your Application After Deployment

Server selection is only the first step. Monitor CPU utilization, memory usage, disk I/O, response times, and error logs after deployment.

Tools such as Prometheus, Grafana, and Linux system utilities can help identify bottlenecks before they become serious problems.

Final Thoughts

Reliable infrastructure makes application deployment easier, but the best server is the one that matches your actual workload. Evaluate resources, network limits, support, and scalability before making a decision.

Your Background Jobs Are Slowing Down Your API — Here’s How to Fix It

Arthur — Sun, 11 Oct 2026 05:37:59 +0000

Hello, I’m Arthur. I want to talk about a problem that often appears when an application starts growing.

At first, everything works well. Users submit forms, upload files, receive reports, and get quick responses. But as the application becomes busier, some requests start taking several seconds to finish.

The first reaction is often to upgrade the server or optimize the database. Sometimes that helps, but the real problem may be that the application is doing too much work before responding to the user.

1. Understand What Is Blocking the Response

Imagine a user requests a report. Your API receives the request and then:

Fetches information from the database.
Generates a large CSV file.
Sends an email.
Saves an activity log.
Returns the response.

The user must wait for all these operations to finish, even though the email and some other tasks do not need to happen before the response.

This increases response time and can tie up application workers unnecessarily.

2. Move Slow Tasks to a Background Queue

A better approach is to let the API handle the essential work, enqueue the remaining tasks, and return a response without waiting for every task to finish.

A typical architecture looks like this:

flowchart TD
A[User Request] --> B[API Server]
B --> C[Validate and Save Data]
C --> D[Add Job to Queue]
D --> E[Return Response]
D --> F[Background Worker]
F --> G[Generate Report]
F --> H[Send Email]
F --> I[Record Job Status]

Tools such as Celery with Redis or RabbitMQ, and BullMQ for Node.js, can help implement background processing.

The right choice depends on your programming language, workload, and reliability requirements.

3. A Simple Python Example

Python applications can use a queue to separate job submission from job execution.

Here is a simplified example using Python's built-in queue module:

from queue import Queue
from threading import Thread
import time

jobs = Queue()

def process_job():
    while True:
        job = jobs.get()

        try:
            if job is None:
                return

            print(f"Processing: {job}")
            time.sleep(2)  # Simulate slow work
            print(f"Finished: {job}")

        finally:
            jobs.task_done()

worker = Thread(target=process_job, daemon=True)
worker.start()

jobs.put("generate-monthly-report")
jobs.put("send-notification")

print("Jobs submitted")

This demonstrates the basic idea, but it is not a production-ready distributed queue. The queue exists only in memory, so jobs can be lost if the process stops. For production systems, consider a durable broker, retries, monitoring, and safe shutdown behavior.

4. Design Jobs to Handle Retries Safely

Background jobs can fail because an external API is unavailable, a network connection drops, or a database temporarily rejects a request.

A reliable worker should have a retry policy with a reasonable delay. However, retrying can accidentally perform the same operation twice.

For example, a payment notification might be sent twice if the worker completes the operation but crashes before recording success.

Use idempotency where possible: processing the same job more than once should not create duplicate side effects.

Also consider:

Setting a maximum retry count.
Moving repeatedly failing jobs to a dead-letter queue.
Recording failure reasons.
Alerting when the queue backlog grows unexpectedly.

5. Monitor the Queue, Not Just the API

Your API may respond quickly while background jobs fall further behind.

Track metrics such as:

Queue depth: how many jobs are waiting?
Job age: how long has the oldest job been waiting?
Processing time: how long does each job take?
Failure rate: how many jobs fail or need retries?
Worker utilization: are workers busy, idle, or overloaded?

These measurements help you determine whether you need more workers, faster job processing, or a better queue design.

6. Give Background Workers Enough Resources

Background jobs still consume CPU, memory, disk, and network bandwidth. Moving work out of the API does not make that workload disappear.

For example, generating thousands of reports can consume significant memory. Running too many workers simultaneously may slow down the database or affect the API.

If you deploy your application on a VPS, review the available CPU, RAM, storage, and network capacity before deciding how many workers to run. You can compare options such as HelloServer VPS hosting against your application's actual workload and resource requirements.

Start with a manageable number of workers, measure performance, and increase concurrency gradually.

7. Know When Background Processing Is Worth It

Not every operation needs a queue. A small, fast database query usually belongs in the normal request flow.

Background processing is particularly useful for tasks such as:

Sending emails and notifications.
Generating large reports.
Processing uploaded media.
Synchronizing data with external services.
Running scheduled cleanup tasks.

Keep essential validation and operations that must succeed before confirming a transaction in the main request flow. The goal is not to move everything into a queue; it is to move work that can safely happen later.

Final Thoughts

Slow APIs are not always caused by weak hardware or inefficient queries. Sometimes the application is simply waiting for work that does not need to happen immediately.

Separate slow tasks from user-facing requests, make jobs safe to retry, and monitor queue performance. These changes can improve responsiveness without requiring a complete rewrite.

The best optimization is often not doing the same work faster, but organizing the work so users do not have to wait for it.

Why Your Database Gets Slower as Your App Grows

Arthur — Sat, 10 Oct 2026 04:24:22 +0000

Hello, I’m Arthur. One problem developers often face is that an application works perfectly when it has a few hundred records, but starts slowing down when the database grows.

At first, everything seems fine. Pages load quickly, API responses are fast, and database queries finish almost instantly.

Then the application grows. More users join, more records are stored, and suddenly a query that used to take milliseconds takes several seconds.

The first reaction is often to upgrade the server. But sometimes, the real problem is the way the database is being queried.

1. Stop Fetching Every Record

Consider this query:

SELECT * FROM orders;

It returns every column and every row in the orders table.

That might be fine for a small test database, but it can become expensive when the table contains millions of records.

If your application only needs an order ID, status, and creation date, request those fields instead:

SELECT id, status, created_at
FROM orders;

You reduce the amount of data the database needs to return and the application needs to process.

For large tables, you should also limit the number of rows returned.

2. Add Indexes Where They Actually Help

Imagine your application frequently searches for orders belonging to a particular customer.

Without a suitable index, the database may need to examine many rows to find matching records.

You could create an index like this:

CREATE INDEX idx_orders_customer_id
ON orders(customer_id);

Now the database has an additional structure it can use to locate matching rows efficiently.

However, indexes aren't free. They consume storage and can make inserts, updates, and deletes more expensive.

Before adding an index, inspect the query plan using EXPLAIN in your database system. Test the change against realistic data.

3. Avoid the N+1 Query Problem

Suppose an application fetches 100 blog posts and then runs another query to retrieve each author's name.

That can result in 101 database queries instead of one or a few efficient queries.

A join can often help:

SELECT
    posts.id,
    posts.title,
    authors.name
FROM posts
JOIN authors
    ON posts.author_id = authors.id;

The best approach depends on your schema and application, but the key idea is to avoid repeatedly querying the database for related information when it can be fetched more efficiently.

4. Use Pagination for Large Results

Returning thousands of records in one request can increase database work, memory usage, and response time.

A simple SQL example is:

SELECT id, title, created_at
FROM posts
ORDER BY created_at DESC, id DESC
LIMIT 20;

For a small dataset, LIMIT and OFFSET may be enough. For very large datasets, cursor-based pagination can perform better because large offsets may still require the database to scan and discard many rows.

5. Measure Before Changing the Server

When a database becomes slow, check:

Which queries take the longest?
Are indexes being used?
Are too many queries running per request?
Is the connection pool exhausted?
Is the database waiting on disk operations?
Are multiple transactions blocking one another?

These checks help distinguish a query problem from a resource problem.

If you've optimized your queries and confirmed that the database needs more resources, then reviewing CPU, RAM, storage performance, and network latency makes sense.

For applications that need more control over their hosting environment, you can compare HelloServer VPS hosting with other providers and evaluate the resources against your database workload.

Keep in mind that hosting specifications alone don't guarantee database performance. Configuration, workload, and storage behavior matter too.

6. A Simple Optimization Workflow

When a query becomes slow, follow this process:

Measure its execution time.
Inspect the query plan.
Check the columns used in filters and joins.
Review indexes and unnecessary data retrieval.
Test the optimized query with realistic data.
Measure again and compare the results.

Change one thing at a time so you can understand what actually improved performance.

Final Thoughts

A growing database doesn't automatically require a bigger server.

Sometimes, selecting fewer columns, adding a carefully chosen index, fixing repeated queries, or introducing better pagination can make a noticeable difference.

The goal isn't to optimize every query blindly. It's to find the queries that matter, measure their behavior, and improve them based on evidence.

How to Find and Fix Memory Leaks in Python

Arthur — Fri, 09 Oct 2026 17:06:52 +0000

Hello, I’m Arthur. Have you ever noticed a Python application using more and more RAM even though you're not doing anything unusual?

At first, everything works fine. After a few hours, the application becomes slower. Eventually, it may crash with an out-of-memory error.

Restarting the application might temporarily fix the problem, but it doesn't solve the underlying issue.

One possible cause is a memory leak.

What Causes Memory Leaks in Python?

Python automatically manages memory, so you don't normally need to free objects manually.

However, objects can remain in memory when your application still holds references to them.

Common examples include:

Storing every request in a list.
Keeping old results in an unlimited cache.
Accidentally retaining large objects.
Running background tasks that accumulate data.
Holding references to objects that are no longer needed.

Let's look at a simple example.

1. Understand the Problem

Imagine an application that saves every incoming request:

requests_log = []

def handle_request(data):
    requests_log.append(data)

If the application receives thousands of requests, this list continues growing.

If each item contains a large amount of data, memory consumption can increase significantly.

A better approach might be to keep only the most recent entries:

from collections import deque

requests_log = deque(maxlen=1000)

def handle_request(data):
    requests_log.append(data)

Now the collection retains at most 1,000 entries. Choose an appropriate limit for your application, and avoid storing sensitive request data unnecessarily.

2. Track Memory With `tracemalloc`

Python includes a built-in module called tracemalloc that helps identify where Python allocations are happening.

You don't need to install another package.

import tracemalloc

tracemalloc.start()

# Run the code you want to investigate here.
data = [bytearray(1024) for _ in range(10000)]

snapshot = tracemalloc.take_snapshot()

for stat in snapshot.statistics("lineno")[:10]:
    print(stat)

This shows the source locations responsible for the largest tracked memory allocations.

For a real application, take snapshots at different times and compare them:

before = tracemalloc.take_snapshot()

# Run the workload you want to investigate.

after = tracemalloc.take_snapshot()

for stat in after.compare_to(before, "lineno")[:10]:
    print(stat)

If the same part of your application keeps accumulating allocations, investigate that code first.

Remember that tracemalloc tracks Python memory allocations, not every possible source of process memory usage.

3. Check the Application's RAM Usage

You can also monitor the Python process with psutil.

Install it:

pip install psutil

Then run:

import os
import psutil

process = psutil.Process(os.getpid())

memory = process.memory_info()

print(f"RSS memory: {memory.rss / 1024**2:.2f} MB")

RSS represents the physical memory currently resident for that process.

Run this measurement at regular intervals while testing your application. If memory usage continually rises under the same workload, investigate further before assuming that you have found a leak.

4. Be Careful With Caches

Caching can improve performance, but an unlimited cache can create a memory problem.

For example:

cache = {}

def get_result(key, result):
    cache[key] = result
    return cache[key]

If every request creates a new key, the dictionary may grow indefinitely.

One solution is to use a cache with a maximum size. For example, Python's functools.lru_cache supports a size limit:

from functools import lru_cache

@lru_cache(maxsize=500)
def calculate_result(number):
    return number * number

This works well for suitable repeatable calculations. For applications where cached data changes frequently, consider expiration rules or an appropriate external cache.

5. Why This Matters on a VPS

Memory leaks are especially important in long-running services, APIs, bots, workers, and background jobs.

A process that gradually consumes more RAM can affect other applications running on the same server.

When choosing infrastructure for a Python application, consider memory requirements, CPU allocation, storage, and expected traffic. If you're comparing hosting options, HelloServer VPS hosting is one place to review alongside other providers.

But adding more RAM should not replace investigating a memory problem. More resources may delay the symptoms without fixing the cause.

Final Thoughts

When a Python application becomes slower over time, don't immediately assume the server is too small.

Measure memory usage, compare allocation snapshots, inspect growing collections, and test the application under a repeatable workload.

The most useful debugging process is the one that helps you find the cause rather than repeatedly restarting the application.

What Actually Happens When You Type a URL in Your Browser?

Arthur — Thu, 08 Oct 2026 17:10:28 +0000

Hello, I’m Arthur. I used to think opening a website was simple: type the URL, press Enter, and the page appears.

But quite a lot happens between those two moments.

Your browser has to find the server, establish a connection, send a request, receive the response, and then build the page you see.

Let’s break it down.

1. The Browser Reads the URL

Suppose you enter:

https://example.com/products

The browser separates this into different parts:

https://     → Protocol
example.com  → Domain
/products    → Path

The browser now knows that it needs to communicate with the website using HTTPS.

2. DNS Finds the Server

Computers communicate using IP addresses, not domain names.

So the browser needs to find the IP address behind:

example.com

This is where DNS comes in.

You can think of DNS as the internet's phone book.

For example:

example.com
      ↓
DNS lookup
      ↓
93.184.xxx.xxx

The browser can now contact the correct server.

3. The Connection Is Established

With HTTPS, the browser needs to establish a secure connection with the server.

This involves TLS, which encrypts the communication between your browser and the website.

This is why you see:

https://

instead of:

http://

for most modern websites.

4. The Browser Sends an HTTP Request

The browser then sends a request to the server.

A simplified request might look like:

GET /products HTTP/1.1
Host: example.com

The server receives the request and decides what response to return.

It might return an HTML page, an image, JSON data, or something else.

5. The Server Does Its Work

This is where the hosting environment becomes important.

A simple static website may only need to return an HTML file.

A dynamic application might need to:

Request
   ↓
Web server
   ↓
Application
   ↓
Database
   ↓
Application
   ↓
Response

For example, an online store may need to query a database before showing the products.

If the server is overloaded or the database is slow, the browser has to wait.

6. The Browser Receives the Response

The server might respond with:

HTTP/1.1 200 OK
Content-Type: text/html

followed by the actual HTML.

The browser starts reading that HTML and discovers other files it needs:

HTML
 ├── CSS
 ├── JavaScript
 ├── Images
 └── Fonts

It then requests those resources as well.

7. The Browser Builds the Page

Finally, the browser processes the HTML, CSS, and JavaScript and turns them into the page you see.

That's why a page can sometimes load the text first and images a moment later.

There are multiple things happening behind the scenes.

Why This Matters for Developers

Understanding this process makes website performance easier to understand.

For example, if DNS is slow, the first connection can be delayed.

If the server takes too long to respond, the browser waits.

If the HTML loads quickly but there are hundreds of large images and JavaScript files, the page can still feel slow.

That's why improving website speed isn't always about buying a faster server.

It can involve:

DNS
Server response time
Database queries
Image sizes
JavaScript
CSS
Caching
CDN configuration
Network latency

Where Does a VPS Fit In?

A VPS gives developers more control over the server environment.

You can configure the web server, install specific software, manage applications, and choose resources according to the workload.

If you're comparing VPS options, HelloServer VPS hosting is one option to look at alongside other providers. The important thing is to compare the actual resources, storage, network, location, and management options rather than choosing only by price.

Final Thought

The next time you type a URL and a website appears almost instantly, remember that your browser didn't simply "open a page."

It found a server, established a connection, sent a request, received data, downloaded additional resources, and rendered everything on your screen.

All of that can happen in just a few seconds.

That's one of the things I find interesting about web development: something that looks simple to a user can involve a surprising number of steps underneath.

I Built a Simple File Backup System With Python for My VPS

Arthur — Wed, 07 Oct 2026 14:40:59 +0000

Hello, I’m Arthur. One thing I learned after working with servers is that having a backup is not enough.

You also need to know where the backup is, when it was created, and whether you can actually restore it.

For a small VPS project, I wanted something simpler than a full backup platform, so I built a small Python script that creates compressed backups automatically.

What the Script Does

The script will:

Select a folder to back up
Create a .tar.gz archive
Add the current date and time to the filename
Store the backup in another directory
Remove old backups after a certain number of days

Here is the basic version:

import tarfile
from pathlib import Path
from datetime import datetime, timedelta

SOURCE = Path("/var/www/mywebsite")
BACKUP_DIR = Path("/home/backups")
KEEP_DAYS = 7

BACKUP_DIR.mkdir(parents=True, exist_ok=True)

timestamp = datetime.now().strftime("%Y-%m-%d_%H-%M")
backup_file = BACKUP_DIR / f"website_{timestamp}.tar.gz"

with tarfile.open(backup_file, "w:gz") as archive:
    archive.add(SOURCE, arcname=SOURCE.name)

print(f"Backup created: {backup_file}")

Now every backup gets a unique name, such as:

website_2026-10-07_19-30.tar.gz

That makes it much easier to identify when a backup was created.

Automatically Remove Old Backups

Keeping every backup forever can eventually fill your disk.

We can remove files older than seven days:

now = datetime.now()

for file in BACKUP_DIR.glob("*.tar.gz"):
    age = datetime.fromtimestamp(file.stat().st_mtime)

    if now - age > timedelta(days=KEEP_DAYS):
        file.unlink()
        print(f"Deleted old backup: {file}")

Now the backup directory won't continue growing forever.

Don't Keep the Only Backup on the Same VPS

This is probably the most important part.

If your VPS has a disk failure and your backup is stored on that same disk, you may lose both.

For anything important, I would keep another copy somewhere else, such as object storage or another server.

A VPS is useful because you get control over the environment, but that also means you need to think about your own backup strategy.

When comparing VPS providers, I would look at storage, backup options, disk type, network, and server location rather than focusing only on CPU and RAM. For example, you can compare these factors with HelloServer VPS hosting and other providers.

Automating the Backup

Linux has a simple tool called cron that can run the script automatically.

Open the cron configuration:

crontab -e

Then add:

0 3 * * * /usr/bin/python3 /home/scripts/backup.py

This runs the backup every day at 3:00 AM.

You can change the time depending on when your server has the least activity.

Always Test Your Backups

A backup that has never been restored is only a theory.

Every once in a while, I would create a test directory and extract one of the backup files:

mkdir backup-test
tar -xzf website_2026-10-07_19-30.tar.gz -C backup-test

Then check whether the important files are actually there.

This simple step can save a lot of trouble later.

Final Thought

You don't always need a complicated backup system for a small project.

A simple automated script can already give you a good starting point.

But the important rule is:

Backup → Store another copy → Test the restore.

That is much safer than simply assuming your backup will work when you need it.

How to Move a Node API From a Free Host to a VPS (Step by Step)

Arthur — Mon, 05 Oct 2026 14:58:09 +0000

Hi, I'm Arthur.

Free hosting is a great way to get your first backend online.

You can build an API, connect a frontend, test your idea, and start getting users without worrying about server costs.

But eventually, you may notice things like cold starts, memory limits, sleeping applications, restricted background processes, or simply no SSH access when something goes wrong.

That's usually when a VPS starts making sense.

Instead of the hosting platform deciding how your application runs, you get your own Linux environment and control over the software, processes, logs, and configuration.

In this guide, I'll move a small Node.js/Express API from a free hosting environment to an Ubuntu VPS.

I'll cover:

Creating a non-root user
Installing Node.js and Nginx
Deploying the application
Running Node with systemd
Configuring Nginx
Adding HTTPS
Creating a simple deployment script

Before You Start

You'll need:

An Ubuntu 22.04 or 24.04 VPS
Root or sudo access
A domain or subdomain
Your Node.js application in a Git repository

I'll use this example domain throughout the guide:

api.example.com

Before continuing, create an A record pointing your domain to the VPS IP address.

DNS changes can take some time, and you'll need the domain working before configuring HTTPS.

If you're looking for a small VPS for testing, HelloServer is one option you can compare. The important thing is that your VPS gives you the root or sudo access needed for the setup below.

1. Create a Non-Root User

You don't want to run your application as root.

Connect to your server:

ssh root@YOUR_SERVER_IP

Create a new user:

adduser deploy
usermod -aG sudo deploy

Copy your SSH configuration:

rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Now open a second terminal and test:

ssh deploy@YOUR_SERVER_IP

Make sure this works before changing your SSH configuration.

Once you've confirmed the new account works, edit:

sudo nano /etc/ssh/sshd_config

Set:

PermitRootLogin no
PasswordAuthentication no

Then restart SSH:

sudo systemctl restart ssh

Keep your existing SSH session open while testing the new login.

That way, if you make a configuration mistake, you still have a working session.

2. Install Node.js and Nginx

Update the server:

sudo apt update && sudo apt upgrade -y

Install the Node.js LTS repository:

curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -

Then install Node.js, Nginx, and Git:

sudo apt install -y nodejs nginx git

Check the versions:

node --version
npm --version
nginx -v

Configure the Firewall

If UFW isn't already configured:

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

The order matters.

Always allow SSH before enabling the firewall, otherwise you can accidentally lock yourself out of the server.

3. Put Your Application on the Server

Move into the deploy user's home directory:

cd /home/deploy

Clone your application:

git clone https://github.com/YOUR_USER/YOUR_REPO.git api

Enter the project:

cd api

Install production dependencies:

npm ci --omit=dev

For testing, your Express application might look something like this:

const express = require('express');

const app = express();

app.get('/health', (req, res) => {
  res.json({ ok: true });
});

app.listen(process.env.PORT || 3000, '127.0.0.1');

Notice that I'm binding the application to:

127.0.0.1

instead of:

0.0.0.0

That's intentional.

Nginx will communicate with Node locally, while the public internet only reaches Nginx.

4. Keep Node Running With systemd

On many free hosting platforms, the provider automatically starts your application again if it crashes.

On your own VPS, you need to configure that yourself.

That's where systemd comes in.

First, create a file for environment variables:

sudo nano /etc/api.env

For example:

DATABASE_URL=postgres://...
JWT_SECRET=change-this

Protect the file:

sudo chmod 600 /etc/api.env

Now create the systemd service:

sudo nano /etc/systemd/system/api.service

Add:

[Unit]
Description=My Node API
After=network.target

[Service]
User=deploy
WorkingDirectory=/home/deploy/api
EnvironmentFile=/etc/api.env
Environment=NODE_ENV=production
Environment=PORT=3000
ExecStart=/usr/bin/node server.js
Restart=always
RestartSec=3

[Install]
WantedBy=multi-user.target

Reload systemd:

sudo systemctl daemon-reload

Start the API:

sudo systemctl enable --now api

Check the logs:

journalctl -u api -f

You can also test the API locally:

curl http://127.0.0.1:3000/health

You should get:

{"ok":true}

The enable command is important because it makes the service start automatically after a server reboot.

5. Put Nginx in Front of Node

Node is running on port 3000, but we don't want users accessing that port directly.

Nginx will act as the reverse proxy.

Create a new Nginx configuration:

sudo nano /etc/nginx/sites-available/api

Add:

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Enable the configuration:

sudo ln -s /etc/nginx/sites-available/api /etc/nginx/sites-enabled/

Test it:

sudo nginx -t

If the configuration is valid:

sudo systemctl reload nginx

Now visit:

http://api.example.com

Your request should reach Nginx first, which then forwards it to Node.

If your Express application uses secure cookies, rate limiting, or other features that depend on the original request information, you may also need:

app.set('trust proxy', 1);

6. Add HTTPS

At this point, the API works over HTTP.

The next step is HTTPS.

Install Certbot:

sudo apt install -y certbot python3-certbot-nginx

Then request a certificate:

sudo certbot --nginx -d api.example.com

Certbot can update the Nginx configuration automatically.

Afterward, test renewal:

sudo certbot renew --dry-run

If everything is configured correctly, your API should now be available over HTTPS.

7. Create a Simple Deploy Script

Manually pulling the repository and restarting the application every time gets old quickly.

Create:

nano /home/deploy/deploy.sh

Add:

#!/usr/bin/env bash

set -e

cd /home/deploy/api

git pull origin main
npm ci --omit=dev

sudo systemctl restart api

echo "Deployed."

Make it executable:

chmod +x /home/deploy/deploy.sh

Now you can deploy with:

./deploy.sh

If you want to run it remotely:

ssh deploy@YOUR_SERVER_IP ./deploy.sh

Later, you can connect this script to GitHub Actions and turn the process into a basic CI/CD workflow.

What You Now Have

At this point, the setup looks roughly like this:

Internet
   |
   v
Nginx :443
   |
   v
Node.js :3000
   |
   v
Your API
   |
   v
Database

Nginx handles the public traffic and HTTPS.

Node handles the application.

systemd makes sure the application stays running.

And your deploy script handles basic updates.

It's a simple setup, but it's enough for many small APIs and personal projects.

What You Take Responsibility For With a VPS

Moving from free hosting to a VPS gives you more control, but that also means more responsibility.

Updates

Keep the operating system and installed packages updated.

You can install automatic security updates with:

sudo apt install unattended-upgrades

Backups

If your database is running on the same server, don't assume the VPS itself is a backup.

For example, PostgreSQL backups can be created with:

pg_dump DATABASE_NAME > backup.sql

But don't keep your only backup on the same server.

If the server disappears, the backup disappears with it.

Monitoring

You don't need an expensive monitoring system for a small project.

A simple uptime monitor checking:

https://api.example.com/health

is a good starting point.

When Should You Actually Move to a VPS?

I wouldn't automatically recommend a VPS for every project.

If you're building a prototype and the free tier works, stay there.

Free hosting can be perfectly fine for learning and testing.

I'd consider moving when:

Your API keeps going to sleep
Cold starts are affecting users
You need background workers
You need a database alongside the API
You need SSH access
You need more control over the server
Your application is consistently hitting CPU or memory limits

The biggest advantage isn't simply getting more resources.

It's getting control.

You decide what runs.

You decide how it is configured.

And when something breaks, you can actually log into the machine and investigate it.

That's the part I appreciate most about having a VPS.

If you're practicing this setup yourself, a small VPS from HelloServer or another provider can be enough to go through the entire process without needing a large production server.

Start small, break things, rebuild the server, and learn what each component actually does.

That's usually more valuable than simply following a deployment tutorial once.

8 VPS Performance Details Developers Should Actually Know

Arthur — Sun, 04 Oct 2026 05:22:02 +0000

Hello, I’m Arthur.

If you work with VPS servers, you probably already know the usual specs: vCPU, RAM, storage, and bandwidth.

But those numbers don't always explain why one server feels faster than another.

Once you start running databases, APIs, containers, background workers, or other demanding workloads, a few less obvious things start to matter.

Here are 8 VPS performance details I think developers should know.

1. Check CPU Steal Time

Your VPS may show low CPU usage and still feel slow.

Why?

In a virtualized environment, your virtual CPU shares physical CPU resources with other workloads.

CPU steal time shows how much time your VM wanted CPU but had to wait for it.

If steal time becomes consistently high, the problem may not be your code.

The underlying host could be heavily loaded.

That's something worth checking before spending time optimizing an application that isn't actually the main problem.

2. vCPU Count Doesn't Tell the Whole Story

“8 vCPU” sounds straightforward.

But 8 vCPUs on one physical CPU platform aren't necessarily equal to 8 vCPUs on another.

CPU generation, architecture, clock behavior, virtualization, and resource allocation can all affect real performance.

For CPU-heavy workloads, benchmarking the actual server is much more useful than comparing the vCPU number alone.

3. NVMe Doesn't Guarantee the Same I/O Performance

Developers often see NVMe and assume the storage problem is solved.

Not necessarily.

Two VPS providers can both offer NVMe while delivering very different I/O performance.

Your workload may depend on:

Random reads
Random writes
Sequential I/O
IOPS
Storage latency
Queue depth

A database can be especially sensitive to random I/O and latency.

So if an application is slow while CPU usage looks normal, check disk latency and I/O wait before assuming you need more CPU.

4. Network Speed and Latency Are Different

A server with a 1 Gbps connection isn't automatically going to give you low-latency connections.

For distributed applications, APIs, databases, and microservices, latency can matter more than maximum bandwidth.

A server might have plenty of bandwidth but a poor network route to another service.

That's why server location can be an actual performance decision, not just a geographical preference.

5. Load Average Isn't Just CPU Usage

Linux load average is another metric that's easy to misunderstand.

A high load doesn't always mean your CPU is running at 100%.

Processes waiting for certain resources, including I/O, can contribute to system load.

For example, you could have a server with moderate CPU usage but a high load because processes are waiting on storage.

Looking at load average together with CPU usage, I/O wait, and disk latency gives you a much clearer picture.

6. Swap Usage Doesn't Automatically Mean You Need More RAM

Seeing swap usage can be alarming.

But a small amount of swap activity doesn't automatically mean the VPS needs more RAM.

Linux can move less frequently used memory pages to swap while keeping RAM available for filesystem caching.

The more important question is whether the system is under memory pressure and actively swapping because it doesn't have enough memory.

Heavy swapping is a different situation.

If the system constantly moves data between RAM and swap, application performance can suffer badly.

7. Containers Still Depend on the Host

Docker makes it easy to run multiple services on a VPS.

But containers don't magically create extra CPU, RAM, or disk performance.

If five containers are competing for the same resources, they can still affect each other.

This is why resource limits and monitoring matter.

For example, a background worker consuming all available CPU can make an API container appear slow even though the API itself hasn't changed.

Container-level monitoring can help identify which service is actually responsible.

8. Bigger VPS Isn't Always the Right Fix

This is probably the most useful lesson.

When an application becomes slow, upgrading from 4 vCPU to 8 vCPU feels like the obvious solution.

Sometimes it works.

Sometimes it doesn't.

If the actual bottleneck is database queries, storage latency, network latency, memory pressure, or an inefficient background process, doubling the CPU won't solve the real problem.

Before upgrading, find the bottleneck.

Check the application.

Check the database.

Check the disk.

Check memory pressure.

Check network behavior.

Then decide what needs to change.

What I Check Before Choosing a VPS

I don't look at the specification table alone anymore.

I try to match the server to the workload.

A PostgreSQL-heavy application has different requirements from a static website.

A Kubernetes cluster has different requirements from a small API.

A data-processing workload may care much more about CPU performance and storage I/O.

If you're comparing VPS providers, HelloServer VPS is one option worth checking alongside other providers, but the important part is matching the resources to what your application actually does.

Final Thought

VPS performance isn't just about how many cores or how much RAM you buy.

The interesting part is what happens when your workload actually starts using those resources.

CPU steal time, I/O wait, storage latency, network routing, memory pressure, and container resource limits can all become bottlenecks.

So the next time a VPS feels slow, don't immediately upgrade it.

Measure first. Find the bottleneck. Then change the resource that is actually limiting you.

The Small Server Mistakes That Can Cause Big Problems

Arthur — Sat, 03 Oct 2026 07:50:52 +0000

Hello, I’m Arthur. I want to share something I learned while working with websites and applications.

When something breaks on a server, we usually look for a big reason.

A server crashed.

The application has too much traffic.

The database is overloaded.

But sometimes the problem starts with something very small.

A forgotten process.

A full disk.

An old log file.

A wrong cron job.

These little things can slowly turn into bigger problems.

A Full Disk Can Break More Than You Expect

This is one of those problems that is easy to miss.

You check CPU usage.

You check RAM.

Everything looks normal.

But your disk is almost full.

Once storage gets close to its limit, applications can start behaving strangely. Logs may fail to write, databases may have trouble, and applications that need temporary files can run into errors.

That's why disk space should be part of regular server monitoring.

Don't wait until the server tells you there is no space left.

Old Logs Can Take More Space Than You Think

Logs are useful.

They help you understand what happened when something goes wrong.

But logs can also grow quietly for weeks or months.

A server running several applications can generate a surprising amount of log data.

If nobody checks them, they can slowly consume storage.

Log rotation and cleanup are simple things, but they can prevent unnecessary problems.

Cron Jobs Can Become a Hidden Problem

Cron jobs are great for automation.

You can use them for backups, reports, cleanup tasks, scripts, and many other jobs.

But here's the problem.

A cron job that takes 10 seconds today might take much longer when your database or number of files grows.

And if the same job starts again before the previous one finishes, you can end up with multiple copies running at the same time.

That can put unnecessary pressure on the server.

So don't just create a cron job and forget about it.

Check what it does and how long it takes.

Running Too Many Services

When setting up a server, it's tempting to install everything you might need.

A web server.

A database.

Docker.

Monitoring.

Control panels.

Extra tools.

Testing software.

But every service adds another process to manage and another thing that may consume resources.

A cleaner server is usually easier to understand.

If you don't need a service, there is little reason to keep it running.

More Server Resources Don't Fix Bad Configuration

Let's say your application is slow.

You move it to a VPS with more CPU and RAM.

The problem is still there.

Why?

Because the problem may not have been the amount of resources.

It could be a slow database query.

A badly configured web server.

A process using too many connections.

A memory leak.

Or an application making unnecessary requests.

This is why I prefer checking the actual bottleneck before upgrading a server.

If you are choosing a VPS for a project, compare the resources with your actual workload. For example, HelloServer VPS offers VPS hosting that can be considered when planning a server setup.

Backups Need to Be Tested

This one sounds obvious, but it's easy to forget.

You create a backup.

The backup finishes successfully.

You assume everything is fine.

But have you ever tried restoring it?

A backup that cannot be restored when you need it isn't very useful.

Even an occasional test restore can give you much more confidence in your backup system.

Security Updates Are Easy to Delay

Developers are busy.

You finish a project and think:

“I'll update the server later.”

Then later becomes next week.

Then next month.

The problem is that servers aren't something you should configure once and forget forever.

Operating systems, packages, frameworks, libraries, and applications can all need updates.

Keeping a simple maintenance routine is much easier than trying to fix everything after a problem appears.

Don't Ignore Small Warning Signs

One of the most useful habits I've developed is paying attention to small changes.

A command that suddenly takes longer.

Disk usage increasing every day.

RAM usage slowly going up.

A backup taking twice as long.

More database connections than usual.

None of these automatically means something is broken.

But they are useful signals.

Small changes can help you find a problem before it becomes a major one.

My Simple Server Checklist

When I manage or troubleshoot a server, I like to keep the basics simple:

Check CPU usage
Check available RAM
Check disk space
Check disk activity
Review important logs
Check running processes
Review cron jobs
Test backups
Keep packages updated
Remove services that aren't needed

You don't need to become a server expert overnight.

Start with these basics and learn what each one tells you.

The Main Lesson

Server management isn't always about fixing huge problems.

A lot of it is noticing small things before they become huge problems.

A little monitoring today can save hours of troubleshooting later.

And when something does go wrong, don't immediately assume that you need a bigger server.

First ask:

What is actually causing the problem?

That question will usually take you further than simply adding more CPU or RAM.

DEV Community: Arthur

When Does a Website Need VPS Hosting?

1. When Basic Hosting Is No Longer Enough

2. What Makes VPS Hosting Different?

3. Check Your Requirements Before Choosing

4. Is VPS Hosting Right for Everyone?

What Happens When a Web Server Runs Out of Memory?

Why Does a Server Need RAM?

What Happens When RAM Is Almost Full?

How to Check Memory Usage in Linux

How Can You Prevent Memory Problems?

Does VPS Hosting Make a Difference?

Final Thoughts

How to Back Up Postgres on a VPS (and Prove the Restore Works)

What you need

Why pg_dump and not a file copy

Step 1: A place for backups

Step 2: Set up offsite storage

Step 3: The script

Step 4: Schedule it and get alerted when it fails

Step 5: The restore drill

If Postgres runs in Docker

Where this setup falls short

Your checklist

Why Developers Need Reliable VPS Hosting for Modern Applications

1. Why Infrastructure Matters

2. VPS vs. Shared Hosting

3. What to Check Before Renting a VPS

4. Monitor Your Application After Deployment

Final Thoughts

Your Background Jobs Are Slowing Down Your API — Here’s How to Fix It

1. Understand What Is Blocking the Response

2. Move Slow Tasks to a Background Queue

3. A Simple Python Example

4. Design Jobs to Handle Retries Safely

5. Monitor the Queue, Not Just the API

6. Give Background Workers Enough Resources

7. Know When Background Processing Is Worth It

Final Thoughts

Why Your Database Gets Slower as Your App Grows

1. Stop Fetching Every Record

2. Add Indexes Where They Actually Help

3. Avoid the N+1 Query Problem

4. Use Pagination for Large Results

5. Measure Before Changing the Server

6. A Simple Optimization Workflow

Final Thoughts

How to Find and Fix Memory Leaks in Python

What Causes Memory Leaks in Python?

1. Understand the Problem

2. Track Memory With tracemalloc

3. Check the Application's RAM Usage

4. Be Careful With Caches

5. Why This Matters on a VPS

Final Thoughts

What Actually Happens When You Type a URL in Your Browser?

1. The Browser Reads the URL

2. DNS Finds the Server

3. The Connection Is Established

4. The Browser Sends an HTTP Request

5. The Server Does Its Work

6. The Browser Receives the Response

7. The Browser Builds the Page

Why This Matters for Developers

Where Does a VPS Fit In?

Final Thought

I Built a Simple File Backup System With Python for My VPS

What the Script Does

Automatically Remove Old Backups

Don't Keep the Only Backup on the Same VPS

Automating the Backup

Always Test Your Backups

Final Thought

How to Move a Node API From a Free Host to a VPS (Step by Step)

Before You Start

1. Create a Non-Root User

2. Install Node.js and Nginx

Configure the Firewall

3. Put Your Application on the Server

4. Keep Node Running With systemd

Why `pg_dump` and not a file copy

2. Track Memory With `tracemalloc`