DEV Community: Vultr

Cleaning Up Docker with Prune

Sanskriti Harmukh — Thu, 29 Oct 2026 17:09:11 +0000

Docker is a widely used containerization platform for building, running, and distributing applications, but as you develop and deploy containers over time, it accumulates unused objects like stopped containers, dangling images, unused volumes, and networks. These leftover resources consume disk space and can degrade system performance if not cleaned up. This guide explains how to use the docker prune command family to safely remove unused Docker resources, covering the differences between docker prune and manual deletion, how to use each prune variant, and how to avoid accidental data loss during cleanup. By the end, you'll have a repeatable set of commands for keeping your Docker host's disk usage under control.

What Is docker prune?

The docker prune command family removes unused Docker resources — stopped containers, dangling images, unused volumes, networks, and build cache — all in one go. It's faster and less manual than docker rm or docker rmi.

Feature	`docker rm` / `rmi`	`docker prune`
Removes one item at a time	Yes	No
Removes all unused resources at once	No	Yes
Requires specific names or IDs	Yes	No
Safer for manual deletions	Yes	No
Useful for quick cleanup	No	Yes

Use docker rm when you need precision, and docker prune when you want to clean everything efficiently.

Quick Reference

$ docker system prune
$ docker container prune
$ docker image prune
$ docker volume prune
$ docker network prune
$ docker builder prune

Common Options for docker prune

Most docker prune commands support the following options:

Option	Description
`--force`	Skip confirmation prompts. Use carefully to avoid accidental deletions.
`--filter`	Filter resources by criteria such as age. Example: `--filter "until=24h"` removes items older than 24 hours.
`--all`	(For images) Remove all unused images, not just dangling ones.

Use filters to avoid removing recently created resources during cleanup.

Clean All Docker Resources with docker system prune

Removes all unused containers, networks, dangling images, and build cache. Syntax: docker system prune [OPTIONS].

1. Clean up all unused Docker resources interactively:

$ docker system prune

2. Clean up all unused resources without confirmation:

$ docker system prune --force

3. Clean up unused resources older than 48 hours:

$ docker system prune --filter "until=48h"

When to use: after heavy development or container churn, when disk space is limited, or when no stopped containers or unused images are needed.

Clean Docker Containers with docker container prune

Removes only stopped containers — running containers are not affected. Syntax: docker container prune [OPTIONS].

1. Remove all stopped containers:

$ docker container prune

2. Remove all stopped containers without confirmation:

$ docker container prune --force

3. Remove stopped containers older than 24 hours:

$ docker container prune --filter "until=24h"

When to use: after running short-lived containers during testing or development, when stopped containers pile up over time, or to free up space without affecting running containers.

Clean Docker Images with docker image prune

Removes unused Docker images. By default, it only removes dangling images — images that are untagged and not referenced by any containers. Syntax: docker image prune [OPTIONS].

1. Remove all dangling images:

$ docker image prune

2. Remove all unused images (not just dangling ones):

$ docker image prune --all

3. Remove unused images older than 72 hours:

$ docker image prune --all --filter "until=72h"

When to use: after building or pulling many temporary images, when running out of disk space due to image layers, or to clean up old application builds not referenced by containers.

Clean Docker Volumes with docker volume prune

Removes volumes that are not referenced by any containers. Active or attached volumes are not affected. Syntax: docker volume prune [OPTIONS].

1. Remove all unused volumes interactively:

$ docker volume prune

2. Remove all unused volumes without confirmation:

$ docker volume prune --force

When to use: after deleting containers that previously used persistent volumes, when temporary or test volumes accumulate over time, or to recover disk space tied to orphaned data.

Warning: Volume data is not recoverable after deletion. Always verify which volumes are in use before pruning.

Clean Docker Networks with docker network prune

Removes Docker networks that are not connected to any running or stopped containers. Syntax: docker network prune [OPTIONS].

1. Remove all unused networks interactively:

$ docker network prune

2. Remove all unused networks without confirmation:

$ docker network prune --force

When to use: after removing containers created with docker-compose, when testing multi-container applications, or to clean up orphaned or auto-generated bridge networks.

Clean Docker Build Cache with docker builder prune

Removes the build cache created during image builds. By default, it only removes dangling (unused) cache layers. Syntax: docker builder prune [OPTIONS].

1. Remove dangling build cache interactively:

$ docker builder prune

2. Remove all unused build cache without confirmation:

$ docker builder prune --all --force

When to use: after frequent image builds during development, when low on disk space, or to clean up intermediate cache layers that are no longer referenced.

Troubleshooting Docker Prune Issues

Docker Prune Doesn't Remove Everything

Cause: Docker only removes unused resources. If a container or volume is still referenced, it won't be pruned.

Solution:

1. Stop the container:

$ docker container stop <container_id>

2. Remove the container:

$ docker container rm <container_id>

3. Run prune again:

$ docker system prune

Cannot Delete Volume Because It's In Use

Cause: The volume is still attached to a container.

Solution:

1. List all volumes:

$ docker volume ls

2. Inspect the volume to see where it's used:

$ docker volume inspect <volume_name>

3. Remove the attached container:

$ docker container rm <container_id>

4. Then prune volumes:

$ docker volume prune

Docker Disk Usage Still High

Cause: Some resources are still referenced or were not covered by the last prune command.

Solution:

1. Check the disk usage summary:

$ docker system df

2. Run targeted prune commands:

$ docker image prune

$ docker volume prune

3. Run a full cleanup (if safe to do so):

$ docker system prune --all

Next Steps

Schedule docker system df and a filtered docker system prune --filter "until=24h" as a recurring job instead of running cleanup manually.
Standardize on --filter "until=Xh" across your team's cleanup scripts to avoid accidentally removing resources still in active use.
Add a docker volume ls check to your deployment pipeline before pruning volumes, since volume data isn't recoverable.
Review docker builder prune --all periodically on CI build hosts where cache layers accumulate quickly.

For the full guide with additional tips, visit the original article on Vultr Docs.

Using Volumes in Docker

Sanskriti Harmukh — Thu, 29 Oct 2026 17:08:50 +0000

Docker volumes are a persistent storage mechanism that decouples your data from the container lifecycle, letting containers retain data across restarts and removals and allowing multiple containers to share a common data source. Unlike bind mounts, Docker manages volumes internally and stores them under /var/lib/docker/volumes/ on Linux systems. This guide shows how to create and inspect Docker volumes, interact with their contents, use them in Docker Compose workflows, back up and restore volume data, and reference volumes with the VOLUME instruction in a Dockerfile. By the end, you'll have a container with a named, persistent volume that you can inspect, back up, restore, and manage through both the CLI and Docker Compose.

Quick Reference

The following commands demonstrate how to manage persistent data using volumes:

$ docker volume create web_content
$ docker container run -d -v web_content:/app/data --name volume_demo httpd
$ docker volume ls
$ docker volume inspect web_content
$ docker volume rm web_content
$ docker volume prune

When to Use Docker Volumes

Use Docker volumes instead of bind mounts when:

You want data to persist across container restarts or removals.
You need consistent storage behavior across Linux, macOS, and Windows.
You prefer Docker-managed storage lifecycle and internal volume handling.
You plan to back up or restore application data regularly.
You need to share persistent data between multiple containers.

Bind mounts are more suitable for development environments where code changes on the host need to reflect immediately in the container. For production environments, Docker volumes are the preferred choice due to their portability, safety, and lifecycle integration.

Manually Create and Link Volumes

1. Create a Docker volume:

$ docker volume create web_content

This creates a Docker-managed volume named web_content. Docker stores it internally and tracks its metadata.

Output:

web_content

2. Run a container and mount the volume:

$ docker container run -d -v web_content:/usr/local/apache2/htdocs --name apache_with_volume httpd

This launches a container with the httpd image and mounts the named volume at the web server's root. -d runs the container in detached mode, -v web_content:/usr/local/apache2/htdocs mounts the volume to Apache's web root, and --name apache_with_volume assigns the container a custom name.

Output:

03d0120e51dd822148d4c4c0464473cdad8a916e22ba5685ec495e47573dc722

3. List all volumes:

$ docker volume ls

Output:

DRIVER    VOLUME NAME
local     web_content

4. Inspect the volume:

$ docker volume inspect web_content

This confirms the volume's internal mount path and attributes, useful for debugging and manual access.

Output:

[
   {
       "CreatedAt": "2025-06-06T17:38:52Z",
       "Driver": "local",
       "Labels": null,
       "Mountpoint": "/var/lib/docker/volumes/web_content/_data",
       "Name": "web_content",
       "Options": null,
       "Scope": "local"
   }
]

5. List all containers:

$ docker container ls -a

Output:

CONTAINER ID   IMAGE     COMMAND              CREATED          STATUS          PORTS     NAMES
03d0120e51dd   httpd     "httpd-foreground"   46 seconds ago   Up 45 seconds   80/tcp    apache_with_volume

6. Check volume usage by container:

$ docker container inspect --format={{.Mounts}} apache_with_volume

This shows where the volume is mounted inside the container, validating its usage path.

Output:

[{volume web_content /var/lib/docker/volumes/web_content/_data /usr/local/apache2/htdocs local z true }]

7. Stop the container:

$ docker container stop apache_with_volume

This halts the container without removing it, preserving the volume and data.

Output:

apache_with_volume

8. Remove the container:

$ docker container rm apache_with_volume

This removes the container while leaving the named volume intact for reuse.

Output:

apache_with_volume

9. Remove the volume:

$ docker volume rm web_content

This permanently removes the volume and its contents.

Output:

web_content

Warning: Removing a volume deletes all stored data. Ensure backups exist before running this command in production environments.

Use Volumes in Dockerfiles

While Dockerfiles can't create named volumes, they can define mount points expected at runtime using the VOLUME instruction. Docker automatically creates an anonymous volume for such paths unless you explicitly mount a named one when running the container.

1. Navigate to the user's home directory and create a docker directory:

$ cd ~
$ mkdir docker

2. Navigate into the new directory:

$ cd docker/

3. Create a Dockerfile:

$ nano Dockerfile

4. Add the following content to the Dockerfile:

FROM httpd
VOLUME ["/usr/local/apache2/htdocs"]
CMD ["httpd-foreground"]

Save and close the file. This Dockerfile builds an Apache-based image that treats /usr/local/apache2/htdocs as a volume path.

5. Build the image:

$ docker image build -t apache_with_volume .

This builds the Dockerfile and creates a new image named apache_with_volume.

Output:

[+] Building 0.1s (5/5) FINISHED                            docker:default
 => [internal] load build definition from Dockerfile        0.0s
 => => transferring dockerfile: 110B                        0.0s
 => [internal] load metadata for docker.io/library/httpd    0.0s
 => => writing image sha256:c886f948f696b...                0.0s
 => => naming to docker.io/library/apache_with_volume       0.0s

6. Run the container:

$ docker container run -d --rm apache_with_volume

-d runs the container in detached mode, and --rm automatically removes the container when it exits. Docker automatically creates an anonymous volume and mounts it at /usr/local/apache2/htdocs, as defined in the Dockerfile.

To use a named volume instead of an anonymous one, pass the -v flag explicitly:

$ docker container run -d --rm -v web_content:/usr/local/apache2/htdocs apache_with_volume

This lets you control the volume lifecycle while still benefiting from Dockerfile-defined mount points.

Interact with Docker Volumes

Docker does not let you directly mount volumes on the host system, but you can access and modify volume contents from within a running container.

1. Start a container with the volume mounted:

$ docker container run -d --name apache_with_volume -v web_content:/usr/local/apache2/htdocs httpd

Output:

03d0120e51dd8221...

2. Create an HTML file on your host machine:

$ echo "<h1>Hello Apache from docker volume</h1>" > index.html

3. Copy the file into the container:

$ docker cp index.html apache_with_volume:/usr/local/apache2/htdocs/

Output:

Successfully copied 2.05kB to apache_with_volume:/usr/local/apache2/htdocs/

4. View the file contents inside the container:

$ docker exec apache_with_volume \
   cat /usr/local/apache2/htdocs/index.html

Output:

<h1>Hello Apache from docker volume</h1>

5. Back up the volume from inside the container:

$ docker exec apache_with_volume \
   tar czf /usr/local/apache2/htdocs/httpd_backup.tar.gz -C /usr/local/apache2/htdocs .

This creates a compressed .tar.gz archive of the volume's contents inside the container.

6. Copy the backup file from the container to the host:

$ docker cp apache_with_volume:/usr/local/apache2/htdocs/httpd_backup.tar.gz .

Output:

Successfully copied 2.05kB to /home/john/docker/.

7. Restore the volume by copying the archive back and extracting it:

$ docker cp httpd_backup.tar.gz apache_with_volume:/usr/local/apache2/htdocs/

$ docker exec apache_with_volume \
   tar xzf /usr/local/apache2/htdocs/httpd_backup.tar.gz -C /usr/local/apache2/htdocs

The first command copies the backup archive into the container, and the second extracts its contents into the volume directory.

Use Volumes with Docker Compose

Docker Compose supports named volumes natively — they're automatically created and managed alongside the service lifecycle.

1. Create a docker-compose directory in your home path:

$ cd ~
$ mkdir docker-compose

2. Navigate to the new directory:

$ cd docker-compose/

3. Create a docker-compose.yml manifest:

$ nano docker-compose.yml

4. Add the following YAML content to the file:

services:
   web:
       image: httpd
       volumes:
           - web_content:/usr/local/apache2/htdocs

volumes:
   web_content:

This tells Docker Compose to create a volume named web_content and mount it to the container at /usr/local/apache2/htdocs.

5. Start the service:

$ docker compose up -d

This builds and runs the container while automatically creating the declared volume and network.

Output:

[+] Running 3/3
✔ Network docker-compose_default       Created                    0.2s 
✔ Volume "docker-compose_web_content"  Created                    0.0s 
✔ Container docker-compose-web-1       Started                    0.6s

6. Inspect the volume created by Docker Compose:

$ docker volume inspect docker-compose_web_content

Replace docker-compose_web_content with the name of your Docker Compose volume. This confirms that the named volume declared in the Compose file was created and is mounted as expected.

Output:

[
    {
        "Name": "docker-compose_web_content",
        "Mountpoint": "/var/lib/docker/volumes/docker-compose_web_content/_data",
        ...
    }
]

7. Shut down the service and remove the volume:

$ docker compose down -v

down stops and removes containers, networks, and volumes, and -v ensures that named volumes declared in the Compose file are also deleted.

Output:

[+] Running 3/3
✔ Container docker-compose-web-1     Removed                      1.3s 
✔ Network docker-compose_default     Removed                      0.2s 
✔ Volume docker-compose_web_content  Removed                      0.0s

Next Steps

Move your own stateful services (databases, CMS uploads, app data) from bind mounts to named volumes for safer, more portable persistence.
Script the backup/restore workflow (tar inside the container + docker cp) into a reusable shell script you can run on a schedule.
Add volume definitions to an existing Docker Compose project instead of managing volumes manually with the CLI.
Review docker volume prune to clean up unused volumes once you're comfortable with which ones are safe to remove.

For the full guide with additional tips, visit the original article on Vultr Docs.

Using the Find Command in Linux

Sanskriti Harmukh — Thu, 29 Oct 2026 17:08:22 +0000

The find command in Linux is a powerful and versatile utility for searching or locating files and directories in a file system. It uses file attributes like name, size, time, and permissions to perform the search, and you can combine it with other commands to perform complex searches. This guide walks through the basic syntax, the most common options, and practical and advanced examples using a set of sample files and directories. By the end, you'll have a working set of find commands for searching, filtering, and acting on files by name, type, size, time, owner, and permissions.

The find Command Syntax

The basic find command syntax is:

find [path] [expression]

[path] specifies the directory to search and defaults to the working directory (.) if you don't specify one. [expression] combines options, tests, and actions to filter and manipulate the search results, such as filename, file type, size, and modification time.

Set Up Example Directories and Files

1. Switch to your user's home directory:

$ cd

2. Create demo.txt, Demo.txt, and DEMO.txt sample files:

$ touch demo.txt Demo.txt DEMO.txt

3. Create dir and dir1 directories, then create a sub_dir sub-directory under dir1:

$ mkdir -p dir dir1/sub_dir

4. Create a new file.txt text file:

$ touch file.txt

5. Change the file.txt file permissions mode to 755:

$ chmod 755 file.txt

Most Common find Command Options

The find command supports the following options for refining search results:

Option	Description
`-name`	Searches for files and directories with a specific name.
`-iname`	Case-insensitive version of `-name`.
`-type`	Searches for files of a specific type (`f` for regular files, `d` for directories).
`-size`	Searches for files of a specific size (for example, `+100M` for files larger than 100 MB).
`-mtime`	Searches for files modified within a specific number of days (for example, `-7` for files modified in the last 7 days).
`-atime`	Searches for files accessed within a specific number of days.
`-user`	Searches for files owned by a specific user.
`-group`	Searches for files owned by a specific group.
`-perm`	Searches for files with specific permissions (for example, `755`).
`-exec`	Executes a command on each matched file.
`-delete`	Deletes the matched files.
`-ls`	Lists the matched files in `ls -dils` format.
`-print`	Prints the full filename on the standard output.

Practical find Command Examples

1. Find a file named demo.txt in your working directory and subdirectories:

$ find . -name "demo.txt"

2. Perform a case-insensitive search for all files that match demo.txt:

$ find . -iname "demo.txt"

3. Find all directories in the working directory:

$ find . -type d

4. Find files by size, for example files larger than 100MB:

$ find . -size +100M

5. Find files by modification time, for example files modified in the last 7 days:

$ find . -mtime -7

6. Find files by access time, for example files accessed in the last 7 days:

$ find . -atime -7

7. Find all files owned by a specific user, such as demo_user:

$ find . -user demo_user

8. Find all files owned by a specific group, such as demo_user:

$ find . -group demo_user

9. Find all files with 755 permissions:

$ find . -perm 755

The 755 permission means the owner can read, write, and execute the file, while others can only read and execute it.

Advanced find Command Options

1. Execute a command on each matching file using -exec:

$ find . -name "demo.txt" -exec ls -l {} \;

This finds all files named demo.txt and runs ls -l on each one to list them in long format. {} is a placeholder for the matched filename, and \; marks the end of the command to execute.

2. Delete all files named demo.txt:

$ find . -name "demo.txt" -delete

3. Find all .txt files and copy them to another directory:

$ find . -name "*.txt" -exec cp {} /path/to/directory/ \;

This finds all .txt files and copies them to /path/to/directory/, with the filename replacing {} during execution. Replace /path/to/directory with your actual path.

4. Find all .txt files and move them to another directory:

$ find . -name "*.txt" -exec mv {} /path/to/directory/ \;

5. Find all .txt files owned by a specific user, such as demo_user, and modified in the last 7 days:

$ find . -name "*.txt" -user demo_user -mtime -7

This combines -name, -user, and -mtime to create a more specific search.

Interactive find Command Examples

1. Find all files named Demo.txt and list them with detailed information:

$ find . -name "Demo.txt" -exec ls -l {} \;

This uses ls -l to display detailed information about each matched file, such as permissions, owner, size, and modification date.

2. Combine find with wc to locate all files named Demo.txt and count them:

$ find . -name "Demo.txt" | wc -l

This pipes the results to wc -l, which counts the number of matching lines.

3. Find all files with 644 permissions and change them to 600:

$ sudo find . -perm 644 -exec chmod 600 {} \;

This finds all files with 644 permissions and changes the mode to 600 using chmod. {} represents the filename, and \; marks the end of the command.

Next Steps

Combine -mtime, -size, and -user filters to build a single targeted cleanup command for your own file system.
Swap -exec ls -l {} \; for -exec rm {} \; or -delete once you've confirmed a search matches exactly the files you expect — always dry-run with -exec ls first.
Pair find with xargs for better performance on very large result sets instead of -exec.
Look into find's -newer test for finding files modified more recently than a reference file.

For the full guide with additional tips, visit the original article on Vultr Docs.

Processing Text with Bash Using Grep, Sed, and Awk Commands

Sanskriti Harmukh — Thu, 29 Oct 2026 17:07:52 +0000

Text processing in Bash using the grep, sed, and awk commands lets you filter and manipulate input to perform specific tasks, such as searching log files, transforming content, and extracting structured data. You can combine these commands with loops, conditional statements, and expressions for more advanced processing. This guide walks through each tool individually and then shows how to combine them in real scripts. By the end, you'll have working Bash scripts that filter, rewrite, and report on a log file using grep, sed, and awk together.

1. Create a New Bash Script

1. Create a new log.txt file to store multiple lines of text:

$ nano log.txt

2. Add the following contents to the log.txt file:

2024-10-25 08:15:23 INFO: Apache Web Server Application started successfully.
2024-10-25 09:00:01 ERROR: Unable to connect to the database on port 3306.
2024-10-25 09:30:45 WARNING: The Disk space running low.
2024-10-24 10:15:12 INFO: root User logged in.
2024-10-24 10:45:55 ERROR: File not found: www.yml.
2024-10-24 11:15:00 WARNING: High memory usage detected.
2024-10-23 14:25:01 INFO: A scheduled backup is complete.
2024-10-23 15:00:00 ERROR: Apache: The Network connection lost.
2024-10-23 16:20:30 INFO: root User logged out successfully.
2024-10-23 18:45:10 WARNING: CPU temperature exceeding normal level.

Save and close the file.

3. Create a new processing.sh Bash script that loads the log.txt file into a variable:

$ nano processing.sh

4. Add the following contents to the processing.sh file:

#!/bin/bash

LOG="log.txt"

Save and close the file. The LOG variable holds log.txt as input — you'll process this variable with grep, sed, and awk in the next sections.

2. Use the grep Command to Process a Text File

The grep command searches for specific text patterns in files, such as the log.txt file you created, and outputs the results for further processing in a Bash script.

1. Open the processing.sh script:

$ nano processing.sh

2. Add the following command at the end of the file:

grep -i "ERROR" "$LOG"

Save and close the file. This grep command searches for the term ERROR in log.txt and displays all matching results.

3. Run the script using Bash:

$ bash processing.sh

Output:

2024-10-25 09:00:01 ERROR: Unable to connect to the database on port 3306.
2024-10-24 10:45:55 ERROR: File not found: www.yml.
2024-10-23 15:00:00 ERROR: Apache: The Network connection lost.

3. Use the awk Command to Process a Text File

The awk command analyzes structured data and searches for specific patterns in a file. You can use it to customize file contents, split lines into fields or columns for processing, and match specific patterns.

1. Open the processing.sh Bash script:

$ nano processing.sh

2. Add the following contents to the file:

awk '{print $1, $3}' "$LOG"

Save and close the file. This awk command prints the first and third columns in log.txt to display the date and log level.

3. Run the script using Bash:

$ bash processing.sh

Output:

2024-10-25 INFO:
2024-10-25 ERROR:
2024-10-25 WARNING:
2024-10-24 INFO:
2024-10-24 ERROR:
2024-10-24 WARNING:
2024-10-23 INFO:
2024-10-23 ERROR:
2024-10-23 INFO:
2024-10-23 WARNING:

4. Use the sed Command to Process a Text File

Stream Editor (sed) searches, modifies, and replaces content in standard input or a specific file.

1. Open the processing.sh Bash script:

$ nano processing.sh

2. Add the following command at the end of the file:

sed -e 's/ERROR/New ERROR/gI' -e 's/WARNING/New WARNING/gI' "$LOG"

Save and close the file. This sed command replaces ERROR with New ERROR and WARNING with New WARNING in log.txt.

3. Run the script using Bash:

$ bash processing.sh

Output:

2024-10-25 08:15:23 INFO: Apache Web Server Application started successfully.
2024-10-25 09:00:01 New ERROR: Unable to connect to the database on port 3306.
2024-10-25 09:30:45 New WARNING: The Disk space running low.
2024-10-24 10:15:12 INFO: root User logged in.
2024-10-24 10:45:55 New ERROR: File not found: www.yml.
2024-10-24 11:15:00 New WARNING: High memory usage detected.
2024-10-23 14:25:01 INFO: A scheduled backup is complete.
2024-10-23 15:00:00 New ERROR: Apache: The Network connection lost.
2024-10-23 16:20:30 INFO: root User logged out successfully.
2024-10-23 18:45:10 New WARNING: CPU temperature exceeding normal level.

5. Combine grep, sed, and awk Commands

You can combine grep, sed, and awk to analyze and manipulate large inputs with pipes.

1. Create a new combine.sh Bash script:

$ nano combine.sh

2. Add the following contents to the file:

#!/bin/bash

LOG="log.txt"

echo "Processing the log file: $LOG"

echo "Date       Time        Log Level   Message"
echo "------------------------------------------"

grep -E 'ERROR|WARNING' "$LOG" | sed -e 's/ERROR/New ERROR/gI' -e 's/WARNING/New WARNING/gI' "$LOG" | awk '{print $1, $2, $3, $4, $5, $6, $7}'

echo -e "\nLog processing complete."

Save and close the file. The combined grep, sed, and awk commands use pipes (|) to pass the output of each command to the next and display the modified contents of log.txt in a structured format.

3. Run the script using Bash:

$ bash combine.sh

Output:

Processing the log file: log.txt
Date       Time        Log Level   Message
------------------------------------------
2024-10-25 08:15:23 INFO: Apache Web Server Application
2024-10-25 09:00:01 New ERROR: Unable to connect
2024-10-25 09:30:45 New WARNING: The Disk space
2024-10-24 10:15:12 INFO: root User logged in.
2024-10-24 10:45:55 New ERROR: File not found:
2024-10-24 11:15:00 New WARNING: High memory usage
2024-10-23 14:25:01 INFO: A scheduled backup is
2024-10-23 15:00:00 New ERROR: Apache: The Network
2024-10-23 16:20:30 INFO: root User logged out
2024-10-23 18:45:10 New WARNING: CPU temperature exceeding

Log processing complete

6. Use grep, sed, and awk with Conditional Bash Statements

You can use grep, sed, and awk with if-else, case, and if-then statements to enhance output readability and handle errors.

1. Create a new conditional-processing.sh Bash script:

$ nano conditional-processing.sh

2. Add the following contents to the conditional-processing.sh file:

#!/bin/bash

LOG="log.txt"

if [[ -f "$LOG" ]]; then
    echo "Processing the log file: $LOG"

    if grep -qE 'ERROR|WARNING' "$LOG"; then

        echo "Date       Time        Log Level   Message"
        echo "------------------------------------------"

        grep -E 'ERROR|WARNING' "$LOG" | sed -e 's/ERROR/New ERROR/gI' -e 's/WARNING/New WARNING/gI' "$LOG" | awk '{print $1, $2, $3, $4, $5, $6, $7}'

        echo -e "\nLog processing complete."
    else
        echo "No ERRORs or WARNINGs found in the log file."
    fi
else
    echo "The Log file: $LOG is not available"
fi

echo "...............Completed.............."

Save and close the file. The outer if-else validates the input variable, and the inner if-else runs a grep condition to find ERROR or WARNING entries — the combined grep, sed, and awk commands run only when that condition is true.

3. Run the script using Bash:

$ bash conditional-processing.sh

Output:

Processing the log file: log.txt
Date       Time        Log Level   Message
------------------------------------------
2024-10-25 08:15:23 INFO: Apache Web Server Application
2024-10-25 09:00:01 New ERROR: Unable to connect
2024-10-25 09:30:45 New WARNING: The Disk space
2024-10-24 10:15:12 INFO: root User logged in.
2024-10-24 10:45:55 New ERROR: File not found:
2024-10-24 11:15:00 New WARNING: High memory usage
2024-10-23 14:25:01 INFO: A scheduled backup is
2024-10-23 15:00:00 New ERROR: Apache: The Network
2024-10-23 16:20:30 INFO: root User logged out
2024-10-23 18:45:10 New WARNING: CPU temperature exceeding

Log processing complete.
...............Completed..............

7. Use grep, sed, and awk with Bash Loops

Loops such as while, for, and until let you run advanced text processing tasks when using grep, sed, and awk.

1. Create a new loop-combined.sh script:

$ nano loop-combined.sh

2. Add the following contents to the loop-combined.sh file:

#!/bin/bash

LOG="log.txt"

if [ -z "$1" ]; then
    echo "Enter a command option such as `ERROR` or `WARNING`. Example Usage: loop-combined.sh ERROR."
    exit 1
fi


LOG_LEVEL=$1
echo "Filtering '$LOG_LEVEL' logs..."

echo -e "Date       Time        Log Level   Message"
echo -e "------------------------------------------"


grep "$LOG_LEVEL" "$LOG" | 
sed "s/$LOG_LEVEL/${LOG_LEVEL^^}/g" |
awk '{print $1, $2, $3, $4, $5, $6}' |  

while read -r line; do
    echo "New entry: $line"
done

Save and close the file. This script prompts for a log level option and runs a while loop that prints the contents of log.txt using the piped output of grep, sed, and awk one line at a time.

3. Run the script and pass ERROR as the option:

$ bash loop-combined.sh ERROR

Output:

Filtering 'ERROR' logs...
Date       Time        Log Level   Message
------------------------------------------
New entry: 2024-10-25 09:00:01 ERROR: Unable to connect
New entry: 2024-10-24 10:45:55 ERROR: File not found:
New entry: 2024-10-23 15:00:00 ERROR: Apache: The Network

4. Run the script again, passing WARNING as the option:

$ bash loop-combined.sh WARNING

Output:

Filtering 'WARNING' logs...
Date       Time        Log Level   Message
------------------------------------------
New entry: 2024-10-25 09:30:45 WARNING: The Disk space
New entry: 2024-10-24 11:15:00 WARNING: High memory usage
New entry: 2024-10-23 18:45:10 WARNING: CPU temperature exceeding

Next Steps

Adapt conditional-processing.sh to point LOG at a real application or system log instead of the sample file.
Extend the awk pipeline to write matched entries to a separate report file instead of just printing them.
Wrap loop-combined.sh in a cron job to generate a daily filtered summary of ERROR and WARNING entries.
Explore sed's in-place edit flag (-i) for rewriting files directly instead of only streaming output.

For the full guide with additional tips, visit the original article on Vultr Docs.

Checking Disk Space and Usage in Linux

Sanskriti Harmukh — Thu, 29 Oct 2026 17:07:29 +0000

A full disk can degrade system performance, cause services to fail, and even prevent you from logging in or accessing essential directories, so keeping an eye on disk usage is a core part of running any Linux machine. Linux ships with built-in command-line tools — df, du, and find — that let you see how much storage is used, how much is available, and which files or directories are eating it up. This guide walks through practical examples of each tool so you can check disk space, analyze mounted file systems, and troubleshoot disk-related issues efficiently. By the end, you'll have a working set of commands for monitoring disk usage and tracking down large files on any Linux system.

Commands to Check Disk Space and Usage

Linux includes several essential command-line tools that help monitor and manage disk space efficiently:

Command	Description	Typical Use Case
`df`	Displays available and used disk space on mounted filesystems.	Get a high-level overview of all disk partitions.
`du`	Summarizes disk usage of directories and files.	Identify which directories are consuming the most space.
`find`	Searches for existing files and directories based on criteria such as size, name, type, or modification time.	Locate large or old files with specific flags like `-size`, `-mtime`, or `-type`.

How to Check Disk Space with df

The df command provides a quick overview of disk usage across all mounted file systems. Use it to identify partitions with low free space and act before performance is degraded. The basic syntax is df [OPTION]... [FILE].... If you don't pass a file or directory, df displays the disk space for all mounted file systems.

1. Display the disk usage of all mounted file systems in a human-readable format:

$ df -h

Your output should be similar to the one below:

Filesystem      Size  Used Avail Use% Mounted on
...
/dev/vda2       150G   12G  132G   9% /
/dev/vda1       260M  7.1M  253M   3% /boot/efi
tmpfs           768M  4.0K  768M   1% /run/user/1000
/dev/vdb1        40G  1.1G   37G   3% /mnt
/dev/vdc1        40G  375M   40G   1% /home

In the output, Filesystem is the device or file system, Size is its total capacity, Used and Avail are consumed and free space, Use% is the percentage used, and Mounted on is where it's attached.

2. Check disk usage of a specific mount point, such as /mnt:

$ df -h /mnt

Your output should be similar to the one below:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdb1        40G  1.1G   37G   3% /mnt

3. Check disk space for a specific file system type, such as ext4:

$ df -h -t ext4

Your output should be similar to the one below:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2       150G   12G  132G   9% /
/dev/vdb1        40G  1.1G   37G   3% /mnt

4. Exclude a file system type, such as tmpfs, from the output:

$ df -h -x tmpfs

Your output should be similar to the one below:

Filesystem      Size  Used Avail Use% Mounted on
...
/dev/vda2       150G   12G  132G   9% /
/dev/vda1       260M  7.1M  253M   3% /boot/efi
/dev/vdb1        40G  1.1G   37G   3% /mnt
/dev/vdc1        40G  375M   40G   1% /home

5. Include the type of each file system in the output:

$ df -hT

Your output should be similar to the one below:

Filesystem     Type      Size  Used Avail Use% Mounted on
...
tmpfs          tmpfs     1.5G   29M  1.5G   2% /run
/dev/vda2      ext4      150G   12G  132G   9% /
/dev/vda1      vfat      260M  7.1M  253M   3% /boot/efi
/dev/vdb1      ext4       40G  1.1G   37G   3% /mnt
/dev/vdc1      xfs        40G  375M   40G   1% /home

6. Display inode usage, useful for monitoring the number of files and directories:

$ df -i

Your output should be similar to the one below:

Filesystem       Inodes  IUsed    IFree IUse% Mounted on
...
/dev/vda2      41611680 123735 41487945    1% /
/dev/vdb1       2621440     12  2621428    1% /mnt
/dev/vdc1      20971008   2755 20968253    1% /home

Inodes is the total number of inodes on the file system, IUsed and IFree are used and free inodes, and IUse% is the percentage used.

How to Check Disk Usage with du

The du (disk usage) command estimates and displays the disk space used by files and directories, which helps you identify large files or directories that need cleaning up. The basic syntax is du [OPTION]... [FILE].... If you don't pass a file or directory, du shows usage for the current directory.

1. Check disk usage of a specific directory in a human-readable format:

$ sudo du -sh /path/to/directory

It's recommended to use sudo with this command, since some files or directories may require elevated permissions. Here, -s shows only the total (summary) and -h prints sizes in a human-readable format.

2. Include hidden files (those starting with a dot) in the disk usage report:

$ sudo du -ah /path/to/directory

The -a flag includes all files, not just directories, which is useful for finding the disk usage of hidden configuration files too.

3. Exclude certain files or directories from the calculation:

$ sudo du -ah --exclude='*.log' /path/to/directory

--exclude='*.log' excludes all files with the .log extension — useful for ignoring temporary or log files that aren't relevant to the analysis.

4. List the disk usage of top-level subdirectories within a directory, such as /var:

$ sudo du -h --max-depth=1 /var

Your output should be similar to the one below:

...
22M     /var/log
97M     /var/lib
4.0K    /var/yp
4.0K    /var/preserve
216M    /var

5. Sort the directories by disk usage, largest first:

$ sudo du -h --max-depth=1 /var | sort -rh

Your output should be similar to the one below:

216M    /var
97M     /var/lib
97M     /var/cache
22M     /var/log
...

6. Combine find with du to locate large files, such as files larger than 50MB within /var:

$ sudo find /var -type f -size +50M -exec ls -lh {} \;

Your output should be similar to the one below:

-rw-r--r--. 1 root root 65M May  6 20:29 /var/lib/rpm/rpmdb.sqlite

This command lists all files in /var larger than 50 MB, showing each file's size, permissions, and last modification date.

Next Steps

Combine du -h --max-depth=1 | sort -rh on other directories (like /home or /var/log) to build a habit of auditing disk hogs before they become a problem.
Set up a cron job or monitoring alert that runs df -h on a schedule and flags partitions above a usage threshold.
Pair find ... -size +50M with -mtime to clean up old large files safely instead of deleting indiscriminately.
Look into log rotation (logrotate) if /var/log keeps showing up as a top disk consumer.

For the full guide with additional tips, visit the original article on Vultr Docs.

Generating System Hardware Report in Linux

Sanskriti Harmukh — Thu, 29 Oct 2026 17:07:01 +0000

Understanding your system's hardware configuration is essential for developers and system administrators, whether you're verifying hardware compatibility, diagnosing performance issues, or planning upgrades. Linux provides several built-in tools to inspect and report detailed hardware information. This guide demonstrates how to use common Linux utilities to generate system hardware reports, interpret the collected data, and export it in different formats for documentation or troubleshooting. By the end, you'll have a script that generates and archives a complete hardware report for any Linux system.

The Short Answer Version

To quickly view your system's hardware details without generating full reports, use these commands:

$ sudo lshw -short
$ sudo inxi -Fxz
$ sudo dmidecode -t system
$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
$ sudo hwinfo --short

sudo lshw -short — concise hardware tree
sudo inxi -Fxz — readable system summary (serials redacted)
sudo dmidecode -t system — BIOS/system info from firmware
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT — disks/partitions at a glance
sudo hwinfo --short — compact, per-device summary from kernel probes

1. Install Common Tools to Generate Hardware Reports

Most distributions include some of these tools by default, but you can install all of them using your package manager.

On Debian and Ubuntu

1. Update the package list and install the required tools:

$ sudo apt update
$ sudo apt install -y lshw inxi dmidecode hwinfo

On AlmaLinux, Rocky Linux, and RHEL

1. Enable the PowerTools repository:

$ sudo dnf config-manager --set-enabled powertools

For RHEL, the repository name differs. Enable the CodeReady Builder repository instead:

$ sudo dnf config-manager --set-enabled codeready-builder-for-rhel-$(rpm -E %rhel)-$(arch)-rpms

2. Install the perl-JSON-XS dependency:

$ sudo dnf install -y perl-JSON-XS

3. Install the hardware reporting tools:

$ sudo dnf install -y lshw inxi dmidecode hwinfo

Tools Overview

lshw: Displays detailed information about all hardware components, including CPU, memory, storage, and network devices.
inxi: Provides a summarized, human-readable system overview while hiding sensitive identifiers such as serial numbers.
dmidecode: Retrieves hardware and BIOS information directly from system firmware (DMI tables).
hwinfo: Offers comprehensive device-level data, useful for diagnostics and driver verification.

2. System Hardware Deep-Dive: Commands & Examples

CPU

1. View CPU architecture, model, core/thread count, and available instruction sets:

$ lscpu

Output:

Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          40 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   4
  On-line CPU(s) list:    0-3
Vendor ID:                GenuineIntel
  Model name:             Intel Xeon Processor (Skylake, IBRS)
......

The lscpu utility gathers data from /proc/cpuinfo and system firmware. Key fields include Architecture (32-bit, 64-bit, or both), CPU(s) (total available logical cores), and Model name / Vendor ID (useful for identifying virtual CPUs in cloud environments).

Memory (RAM)

1. View real-time memory usage and swap utilization:

$ free -h

Output:

               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       459Mi       6.2Gi       1.3Mi       1.3Gi       7.3Gi
Swap:          8.0Gi          0B       8.0Gi

The "available" field shows the total memory that applications can still use without swapping.

2. Retrieve detailed information about installed DIMMs from system firmware:

$ sudo dmidecode -t memory

Output:

# dmidecode 3.5
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.

Handle 0x1000, DMI type 16, 23 bytes
Physical Memory Array
        Use: System Memory
        Maximum Capacity: 8 GB
        Number Of Devices: 1

Handle 0x1100, DMI type 17, 40 bytes
Memory Device
        Array Handle: 0x1000
        Size: 8 GB
        Type: RAM

This extracts firmware-level data (DMI tables) that includes slot information, maximum capacity, and manufacturer details — useful for verifying the physical memory layout or identifying faulty modules.

Disks & Filesystems

1. List all block devices with their size, type, filesystem format, and mount location:

$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT

Output:

NAME     SIZE TYPE FSTYPE MOUNTPOIN
sr0     1024M rom
vda      160G disk
├─vda1   512M part vfat   /boot/efi
└─vda2 159.5G part ext4   /

Key fields: TYPE (physical disk, partition, or virtual block), FSTYPE (filesystem type, e.g. ext4, xfs, vfat), and MOUNTPOINT (where each partition is mounted). Append -f to lsblk to display filesystem UUIDs and labels.

2. Display mounted filesystems and usage statistics by type:

$ df -hT

Output:

Filesystem     Type      Size  Used Avail Use% Mounted on
efivarfs       efivarfs  256K   19K  233K   8% /sys/firmware/efi/efivars
/dev/vda2      ext4      328G   16G  298G   6% /
/dev/vda1      vfat      511M  6.2M  505M   2% /boot/efi

Key options: -h displays sizes in human-readable format, -T includes the filesystem type.

Network

1. List all network interfaces with assigned IP addresses:

$ ip -br addr

Output:

lo        UNKNOWN    127.0.0.1/8 ::1/128
enp1s0    UP         192.2.0.56/23 2001:db8::5400:5ff:feb2:2f70/64

ip displays and manipulates network interfaces, routes, and addresses; -br enables brief mode; addr lists IP address information for each interface.

2. Display hardware-level details for network interfaces:

$ sudo lshw -class network

Output:

  *-network                 
       description: Ethernet controller
       product: Virtio 1.0 network device
       vendor: Red Hat, Inc.
       ......
       capabilities: msix pm pciexpress bus_master cap_list fb
       configuration: depth=32 driver=virtio-pci latency=0 mode=1280x800 visual=truecolor xres=1280 yres=800
       resources: iomemory:80-7f irq:22 memory:85200000-85200fff memory:800000000-800003fff
     *-virtio0
          description: Ethernet interface
          ......
          serial: 56:00:05:ba:75:dd
          configuration: autonegotiation=off broadcast=yes driver=virtio_net driverversion=1.0.0 ip=155.138.194.201 link=yes multicast=yes

-class network filters lshw output to only show network-related devices.

Whole-System Summaries

1. Readable, redacted system summary:

$ inxi -Fxz

Output:

System:
  Kernel: 6.8.0-79-generic arch: x86_64 bits: 64 compiler: gcc v: 13.3.0
  Console: pty pts/4 Distro: Ubuntu 24.04.3 LTS (Noble Numbat)
Machine:
  Type: Microsoft System: Cloud-VM product: Standard-PC v: pc-q35-8.2 serial: <superuser required>
  Mobo: N/A model: N/A serial: N/A UEFI: Generic v: N/A date: N/A
CPU:
  Info: quad core model: Intel Xeon (Cascadelake) bits: 64 type: MT MCP arch: Cascade Lake rev: 6
    cache: L1: 512 KiB L2: 16 MiB L3: 16 MiB
  Speed (MHz): avg: 2993 min/max: N/A cores: 1: 2993 2: 2993 3: 2993 4: 2993 5: 2993 6: 2993
    7: 2993 8: 2993 bogomips: 47887
......

-F displays full system information (CPU, memory, disks, network, etc.), -x adds extra details like kernel and driver versions, and -z redacts sensitive information (serial numbers, MACs, etc.) for safe sharing.

2. View hardware tree (complete system details):

$ sudo lshw

Output:

demo-server      
    description: Computer
    product: Standard-PC
    vendor: Generic
    version: pc-q35-8.2
    serial: 89766525
    width: 64 bits
    capabilities: smbios-3.0.0 dmi-3.0.0 smp vsyscall32

sudo ensures access to restricted firmware and system data; lshw generates a detailed, hierarchical view of all detected hardware.

3. Compact high-level snapshot of hardware components:

$ sudo hwinfo --short

hwinfo probes and lists system hardware components; --short summarizes output into concise, per-device lines.

3. Exporting Hardware Reports

This section scripts the data collection using lshw, inxi, dmidecode, and hwinfo, storing the output in a timestamped directory. It captures hostname, kernel version, operating system, CPU information, memory usage, and network configuration.

1. Create a new shell script file:

$ nano generate-hw-reports.sh

2. Add the following script to the file. It collects detailed hardware information, organizes the reports, and compresses them into an archive:

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

TS=$(date +"%Y-%m-%dT%H-%M-%S")
HOSTNAME=$(hostname)
REPORT_DIR="hwreports-${HOSTNAME}-${TS}"

echo "==> Creating report directory: ${REPORT_DIR}"
mkdir -p "${REPORT_DIR}"

echo "==> Capturing basic system and network information"
ip route show > "${REPORT_DIR}/routes.txt"
cat /etc/resolv.conf > "${REPORT_DIR}/dns-config.txt"
sudo dmidecode -t bios > "${REPORT_DIR}/bios-info.txt"
uname -a > "${REPORT_DIR}/kernel.txt"
lsb_release -a > "${REPORT_DIR}/os-release.txt" 2>/dev/null || cat /etc/os-release > "${REPORT_DIR}/os-release.txt"
sudo dmidecode -t chassis > "${REPORT_DIR}/chassis.txt"

{
echo "System Hardware Report"
echo "======================="
echo "Host: ${HOSTNAME}"
echo "Generated on: ${TS}"
echo
echo "Files included:"
find "${REPORT_DIR}" -type f | sed 's|^|  - |'
} > "${REPORT_DIR}/INDEX.txt"

cat <<EOF > "${REPORT_DIR}/metadata.json"
{
"hostname": "${HOSTNAME}",
"timestamp": "${TS}",
"kernel": "$(uname -r)",
"os": "$(grep PRETTY_NAME /etc/os-release | cut -d= -f2 | tr -d '"')",
"cpu_count": "$(nproc)",
"cpu_model": "$(lscpu | awk -F: '/Model name/ {print $2}' | xargs)",
"total_memory": "$(free -h | awk '/Mem:/ {print $2}')"
}
EOF

echo "==> Generating human-readable summary (inxi)"
inxi -Fxz > "${REPORT_DIR}/system-summary.txt"

echo "==> Generating hardware tree reports (lshw)"
sudo lshw -sanitize > "${REPORT_DIR}/lshw.txt"
sudo lshw -sanitize -html > "${REPORT_DIR}/lshw.html"
sudo lshw -sanitize -json > "${REPORT_DIR}/lshw.json"

echo "==> Dumping firmware/DMI data (dmidecode)"
sudo dmidecode > "${REPORT_DIR}/dmidecode.txt"

echo "==> Capturing component-specific snapshots"
lscpu > "${REPORT_DIR}/cpu.txt"
free -h > "${REPORT_DIR}/memory-usage.txt"
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT > "${REPORT_DIR}/disks.txt"
ip -br addr > "${REPORT_DIR}/net-addr.txt"

echo "==> Generating full hwinfo report (large)"
sudo hwinfo --all > "${REPORT_DIR}/hwinfo-full.txt"
sudo hwinfo --short > "${REPORT_DIR}/hwinfo-short.txt"

echo "==> Compressing reports into archive"
tar -czf "${REPORT_DIR}.tar.gz" "${REPORT_DIR}/"

echo "==> Done! Archive: ${REPORT_DIR}.tar.gz"
echo "    To extract: tar -xzf ${REPORT_DIR}.tar.gz"

Save and close the file.

3. Grant execute permissions to the script:

$ chmod +x generate-hw-reports.sh

4. Run the script to generate the hardware reports:

$ ./generate-hw-reports.sh

Output:

==> Creating report directory: hwreports-K8s-Cluster-Master--01-2025-10-28T18-06-29
==> Capturing basic system and network information
==> Generating human-readable summary (inxi)

The script creates a timestamped directory containing all hardware reports, then compresses it into a .tar.gz archive for easy backup or sharing.

This script uses -sanitize (for lshw) and -z (for inxi) to remove serial numbers and MAC addresses from the output. Review the generated files before sharing them if your environment treats device IDs or hostnames as sensitive data.

Next Steps

Schedule the script with cron to generate hardware reports on a regular cadence for drift detection.
Diff successive reports to catch unexpected hardware or firmware changes over time.
Feed the metadata.json output into a configuration management database (CMDB) or inventory tool.
Extend the script to capture GPU details with nvidia-smi or lspci on systems with dedicated accelerators.

For the full guide with additional tips, visit the original article on Vultr Docs.

Optimizing GPU Resource Planning with NVIDIA Dynamo

Sanskriti Harmukh — Thu, 29 Oct 2026 17:06:22 +0000

GPU resource allocation for LLM inference presents complex optimization challenges. Workloads exhibit variable request patterns, unpredictable sequence lengths, and strict latency requirements, making static GPU allocation inefficient. Overprovisioning wastes expensive compute resources, while underprovisioning violates service level agreements (SLAs) and degrades user experience. NVIDIA Dynamo's SLA Planner automates GPU resource management through SLA-driven profiling and intelligent autoscaling, analyzing performance requirements (time-to-first-token, inter-token latency), profiling workload characteristics, and dynamically adjusting GPU worker replicas to meet latency targets while minimizing resource consumption. This guide covers deploying Dynamo's SLA Planner on Kubernetes, including infrastructure setup with Prometheus monitoring, DynamoGraphDeploymentRequest (DGDR) configuration for automated profiling and deployment, and Grafana dashboard integration for visualizing scaling decisions and performance metrics. By the end, you'll have a Kubernetes-based LLM deployment that automatically scales GPU workers to meet SLA targets.

Prerequisites

Before you begin, ensure you:

Have access to a Kubernetes cluster with NVIDIA GPUs configured with the NVIDIA GPU Operator. Use a cluster with at least 2 GPU nodes.
Install kubectl and configure it to access your cluster.
Install Helm 3 for package management.
Install jq for JSON processing in command-line operations.
Create an NVIDIA NGC account and generate an NGC API key with NGC Catalog access for pulling container images.
Create a Hugging Face account and generate an access token for gated models like Llama.
Have cluster-admin permissions to install Custom Resource Definitions (CRDs) and create namespaces.

Key Components

This deployment uses several components that work together to provide automated GPU resource planning.

NVIDIA Dynamo Platform provides the orchestration layer with the Dynamo Operator that manages DynamoGraphDeployment (DGD) and DynamoGraphDeploymentRequest (DGDR) resources. The operator automates the profiling, configuration generation, and deployment lifecycle.
SLA Planner acts as the autoscaling controller that monitors inference metrics from Prometheus and adjusts worker replica counts to meet SLA targets. It uses load predictors (constant, ARIMA, Kalman, or Prophet) to forecast request rates and sequence lengths, then calculates optimal GPU allocations based on TTFT (time-to-first-token) and ITL (inter-token latency) requirements.
DynamoGraphDeploymentRequest (DGDR) serves as the declarative interface for deploying models with performance constraints. Users specify the model name, backend type (vLLM, SGLang, or TensorRT-LLM), SLA targets, and container images. The operator automatically profiles the configuration and generates an optimized DynamoGraphDeployment.
DynamoGraphDeployment (DGD) defines the low-level implementation details for a deployed model, including frontend services, prefill workers, decode workers, and the SLA planner component.
Prometheus collects inference metrics from the Dynamo frontend, including request counts, TTFT, ITL, input sequence length (ISL), and output sequence length (OSL).
Grafana visualizes planner decisions, worker counts, GPU usage, observed metrics versus predicted metrics, and correction factors.

1. Verify GPU Availability

1. List GPU nodes in your cluster:

$ kubectl get nodes -o json | jq '.items[] | select(.status.capacity."nvidia.com/gpu") | {name: .metadata.name, gpus: .status.capacity."nvidia.com/gpu"}'

The output displays nodes with available GPUs.

{
  "name": "gpu-node-1",
  "gpus": "2"
}
{
  "name": "gpu-node-2",
  "gpus": "2"
}

2. Verify GPU resources are allocatable:

$ kubectl describe nodes | grep -A 5 "nvidia.com/gpu"

Ensure at least one node shows nvidia.com/gpu: 1 or higher under the Allocatable section.

2. Label GPU Nodes

1. Check if GPU nodes are already labeled:

$ kubectl get nodes --show-labels | grep nvidia.com/gpu.present

If the output displays nodes with the nvidia.com/gpu.present=true label, skip to the next section. If no output appears, proceed with labeling.

2. Identify your GPU nodes:

$ kubectl get nodes

3. Label each GPU node with the Dynamo GPU label. Replace NODE_NAME with your GPU node name:

$ kubectl label node NODE_NAME nvidia.com/gpu.present=true

Repeat this command for each GPU node in your cluster.

4. Verify the labels were applied:

$ kubectl get nodes --show-labels | grep nvidia.com/gpu.present

3. Run Pre-Deployment Checks

1. Clone the Dynamo repository if you haven't already:

$ git clone https://github.com/ai-dynamo/dynamo.git
$ cd dynamo

2. Check out the latest stable release. Visit the Dynamo releases page to find the latest version:

$ git checkout release/0.9.0

3. Run the pre-deployment check script:

$ ./deploy/pre-deployment/pre-deployment-check.sh

The script validates kubectl connectivity, default StorageClass configuration, GPU resources, and GPU Operator installation.

========================================
  Dynamo Pre-Deployment Check Script
========================================

✅ kubectl Connectivity: PASSED
✅ Default StorageClass: PASSED
✅ Cluster GPU Resources: PASSED
✅ GPU Operator: PASSED

All pre-deployment checks passed!
Your cluster is ready for Dynamo deployment.

If any checks fail, review the error messages and resolve the issues before proceeding.

4. Install Prometheus

1. Add the Prometheus Helm repository:

$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
$ helm repo update

2. Install the kube-prometheus-stack with configuration for Dynamo metric scraping:

$ helm install prometheus -n monitoring --create-namespace prometheus-community/kube-prometheus-stack \
    --set prometheus.prometheusSpec.podMonitorSelectorNilUsesHelmValues=false \
    --set-json 'prometheus.prometheusSpec.podMonitorNamespaceSelector={}' \
    --set prometheus.prometheusSpec.probeNamespaceSelector.matchLabels=null

3. Verify Prometheus is running:

$ kubectl get pods -n monitoring -l app.kubernetes.io/name=prometheus

5. Install Dynamo Platform

1. Set environment variables for the installation:

$ export NAMESPACE=dynamo-system
$ export RELEASE_VERSION=0.9.0

2. Navigate to the home directory:

$ cd ~

3. Fetch the Dynamo CRDs Helm chart:

$ helm fetch https://helm.ngc.nvidia.com/nvidia/ai-dynamo/charts/dynamo-crds-${RELEASE_VERSION}.tgz

4. Install the CRDs:

$ helm install dynamo-crds dynamo-crds-${RELEASE_VERSION}.tgz

5. Fetch the Dynamo Platform Helm chart:

$ helm fetch https://helm.ngc.nvidia.com/nvidia/ai-dynamo/charts/dynamo-platform-${RELEASE_VERSION}.tgz

6. Install the Dynamo Platform with the operator enabled and the Prometheus endpoint configured:

$ helm upgrade --install dynamo-platform dynamo-platform-${RELEASE_VERSION}.tgz \
    --namespace ${NAMESPACE} \
    --create-namespace \
    --set dynamo-operator.controllerManager.manager.image.tag=0.9.0 \
    --set grove.enabled=true \
    --set kai-scheduler.enabled=true \
    --set nats.reloader.image.tag=0.22.3 \
    --set prometheusEndpoint=http://prometheus-kube-prometheus-prometheus.monitoring.svc.cluster.local:9090

The command configures the following components:

--namespace ${NAMESPACE} and --create-namespace: Installs the platform in the dynamo-system namespace, creating it if it doesn't exist.
--set dynamo-operator.controllerManager.manager.image.tag=0.9.0: Specifies the Dynamo Operator version that manages DGD and DGDR lifecycle operations.
--set grove.enabled=true: Enables Grove, the distributed runtime that coordinates communication between frontend and worker services.
--set kai-scheduler.enabled=true: Enables the KAI (Kubernetes AI) scheduler for advanced GPU scheduling and resource allocation.
--set nats.reloader.image.tag=0.22.3: Specifies the NATS configuration reloader version that automatically reloads NATS server configuration changes without downtime.
--set prometheusEndpoint=...: Configures the SLA Planner to query inference metrics from the Prometheus service in the monitoring namespace.

If the installation fails with a Grove webhook certificate conflict error, uninstall the release and reinstall:
$ helm uninstall dynamo-platform --namespace ${NAMESPACE}
Then run the installation command again. The warning "tls: failed to find any PEM data in certificate input" is harmless and can be ignored.

7. Verify the operator is running:

$ kubectl get pods -n ${NAMESPACE} -l app.kubernetes.io/name=dynamo-operator

NAME                                                              READY   STATUS      RESTARTS   AGE
dynamo-platform-dynamo-operator-controller-manager-77464cd6pcjt   2/2     Running     0          45s

6. Create Image Pull Secrets

1. Export your NGC API key. Replace YOUR_NGC_API_KEY with your NGC API key from the NGC portal:

$ export NGC_API_KEY=YOUR_NGC_API_KEY

2. Export your Hugging Face token. Replace YOUR_HF_TOKEN with your Hugging Face access token:

$ export HF_TOKEN=YOUR_HF_TOKEN

3. Create a Docker registry secret for NGC access using the exported variable:

$ kubectl create secret docker-registry nvcr-imagepullsecret \
    --docker-server=nvcr.io \
    --docker-username='$oauthtoken' \
    --docker-password=${NGC_API_KEY} \
    -n ${NAMESPACE}

4. Create a Hugging Face token secret for model downloads using the exported variable:

$ kubectl create secret generic hf-token-secret \
    --from-literal=HF_TOKEN=${HF_TOKEN} \
    -n ${NAMESPACE}

7. Select AI Configurator System and Backend Version

The AI Configurator performs offline profiling to generate optimal deployment configurations without running actual workloads. The aicSystem parameter specifies your GPU hardware type, and the aicBackendVersion parameter specifies the inference backend version for profiling data.

Available GPU Systems

System	Description	Supported Backends
`a100_sxm`	NVIDIA A100 SXM	TensorRT-LLM
`b200_sxm`	NVIDIA B200 SXM	SGLang, TensorRT-LLM
`gb200_sxm`	NVIDIA GB200 SXM	TensorRT-LLM
`h100_sxm`	NVIDIA H100 SXM	vLLM, SGLang, TensorRT-LLM
`h200_sxm`	NVIDIA H200 SXM	vLLM, SGLang, TensorRT-LLM
`l40s`	NVIDIA L40S	SGLang, TensorRT-LLM

Backend Version Compatibility

vLLM Backend

GPU System	Supported Versions
H100 SXM	`0.12.0`
H200 SXM	`0.12.0`

Example configuration for vLLM:

sweep:
  useAiConfigurator: true
  aicSystem: h200_sxm
  aicBackendVersion: "0.12.0"

SGLang Backend

GPU System	Supported Versions
B200 SXM	`0.5.6.post2`
H100 SXM	`0.5.6.post2`
H200 SXM	`0.5.6.post2`
L40S	`0.5.5.post3`

Example configuration for SGLang:

sweep:
  useAiConfigurator: true
  aicSystem: h200_sxm
  aicBackendVersion: "0.5.6.post2"

TensorRT-LLM Backend

GPU System	Supported Versions
A100 SXM	`1.0.0`
B200 SXM	`1.0.0rc6`, `1.2.0rc5`
GB200 SXM	`1.0.0rc6`, `1.2.0rc5`
H100 SXM	`1.0.0rc3`, `1.2.0rc5`
H200 SXM	`1.0.0rc3`, `1.2.0rc5`
L40S	`1.0.0`

Example configuration for TensorRT-LLM:

sweep:
  useAiConfigurator: true
  aicSystem: h200_sxm
  aicBackendVersion: "1.2.0rc5"

Selecting the Correct Configuration

Match your configuration to your cluster's GPU hardware: identify your GPU type with kubectl describe nodes, select the matching aicSystem code, and choose a compatible backend version from the tables above. An unsupported combination causes the profiling job to fail with an error indicating no profiling data is available for that configuration.

8. Deploy a Model with SLA-Driven Profiling

1. Create a DGDR manifest file with SLA specifications for the NVIDIA Nemotron Nano 4B model using the vLLM backend:

$ cat << 'EOF' > nemotron-nano-4b-dgdr.yaml
apiVersion: nvidia.com/v1alpha1
kind: DynamoGraphDeploymentRequest
metadata:
  name: nemotron-nano-sla
spec:
  model: nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1
  backend: vllm
  autoApply: false
  profilingConfig:
    profilerImage: nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.9.0-cuda13
    config:
      sla:
        isl: 2000
        osl: 100
        ttft: 300.0
        itl: 30.0
      sweep:
        useAiConfigurator: true
        aicSystem: h200_sxm
        aicHfId: nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1
        aicBackendVersion: "0.12.0"
      planner:
        plannerMinEndpoint: 1
        plannerMaxGpuBudget: 4
        plannerAdjustmentInterval: 30
  deploymentOverrides:
    workersImage: nvcr.io/nvidia/ai-dynamo/vllm-runtime:0.9.0-cuda13
    name: vllm-disagg
EOF

The manifest specifies a Nemotron Nano 4B model with SLA targets (ISL 2000, OSL 100, TTFT 300ms, ITL 30ms), AI Configurator offline profiling for H200 SXM GPUs (20-30 seconds versus 2-4 hours for online profiling), a planner budget of 1-4 GPUs with 30-second adjustment intervals, and autoApply: false so you can review the generated DGD before deployment.

AI Configurator System Selection: The aicSystem parameter must match your GPU hardware type. Available options are: a100_sxm, b200_sxm, gb200_sxm, h100_sxm, h200_sxm, and l40s. The aicBackendVersion parameter must match the available version for your selected system and backend combination. For vLLM backend: H100/H200 SXM supports version 0.12.0. For SGLang: H100/H200 SXM and B200 SXM support version 0.5.6.post2, L40S supports 0.5.5.post3. For TensorRT-LLM: consult the AI Configurator documentation for supported versions.

2. Apply the DGDR manifest:

$ kubectl apply -f nemotron-nano-4b-dgdr.yaml -n ${NAMESPACE}

3. Monitor the DGDR status:

$ kubectl get dgdr nemotron-nano-sla -n ${NAMESPACE} -w

The DGDR transitions through states: Pending → Profiling → Ready.

NAME                MODEL                                    BACKEND   STATE       DGD-STATE   AGE
nemotron-nano-sla   nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1   vllm      Pending                 5s
nemotron-nano-sla   nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1   vllm      Profiling               10s
nemotron-nano-sla   nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1   vllm      Ready                   35s

4. View detailed DGDR status and events:

$ kubectl describe dgdr nemotron-nano-sla -n ${NAMESPACE}

The output displays profiling results and the generated DGD configuration in the status.generatedDeployment field.

9. Extract and Deploy the Generated DGD

1. Extract the generated DGD configuration to a file:

$ kubectl get dgdr nemotron-nano-sla -n ${NAMESPACE} -o jsonpath='{.status.generatedDeployment}' > nemotron-nano-dgd-raw.yaml

2. Add required Pod metadata environment variables and the --trust-remote-code flag to worker services using jq:

$ cat nemotron-nano-dgd-raw.yaml | jq '.spec.services |= with_entries(
    .value.extraPodSpec.mainContainer.env = [
      {"name":"POD_UID","valueFrom":{"fieldRef":{"fieldPath":"metadata.uid"}}},
      {"name":"POD_NAME","valueFrom":{"fieldRef":{"fieldPath":"metadata.name"}}},
      {"name":"POD_NAMESPACE","valueFrom":{"fieldRef":{"fieldPath":"metadata.namespace"}}},
      {"name":"POD_IP","valueFrom":{"fieldRef":{"fieldPath":"status.podIP"}}}
    ] |
    if .value.componentType == "worker" then
      if (.value.extraPodSpec.mainContainer.args // []) | any(. == "--trust-remote-code") | not then
        .value.extraPodSpec.mainContainer.args += ["--trust-remote-code"]
      else
        .
      end
    else
      .
    end
  )' > nemotron-nano-dgd.yaml

This injects Pod metadata environment variables into all services (for Grove distributed runtime coordination) and adds the --trust-remote-code flag only to worker service arguments.

3. Apply the modified DGD configuration to deploy the model:

$ kubectl apply -f nemotron-nano-dgd.yaml -n ${NAMESPACE}

4. Verify the DynamoGraphDeployment was created:

$ kubectl get dgd -n ${NAMESPACE}

NAME          AGE
vllm-disagg   30s

5. Check that the frontend and worker pods are running:

$ kubectl get pods -n ${NAMESPACE} -l app.kubernetes.io/part-of=vllm-disagg

Wait until all pods show Running status before proceeding. Initial deployment may take several minutes as worker pods download the model and load it into GPU memory; monitor with kubectl get pods -n ${NAMESPACE} -w.

10. Test the Deployment

1. Get the frontend service name:

$ kubectl get svc -n ${NAMESPACE} -l nvidia.com/dynamo-discovery-backend=kubernetes | grep frontend

vllm-disagg-frontend   ClusterIP   10.43.69.246   <none>   8000/TCP   2m

2. Forward the frontend service to your local machine:

$ kubectl port-forward -n ${NAMESPACE} svc/vllm-disagg-frontend 8000:8000

Keep this terminal session running.

3. In a new terminal, send a test inference request:

$ curl -X POST http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
      "model": "nvidia/Llama-3.1-Nemotron-Nano-4B-v1.1",
      "messages": [
        {
          "role": "user",
          "content": "Explain GPU resource planning in one sentence."
        }
      ],
      "max_tokens": 50,
      "temperature": 0.7
    }'

4. Press Ctrl+C in the port-forward terminal to stop forwarding.

Production Deployments: Port-forwarding is suitable for local testing only. For production deployments with secure external access, configure Gateway API with TLS encryption to expose the frontend service with HTTPS ingress, load balancing, and certificate management.

11. Install Grafana Dashboard

1. Apply the Grafana dashboard ConfigMap:

$ kubectl apply -n monitoring -f https://raw.githubusercontent.com/ai-dynamo/dynamo/release/0.9.0/deploy/observability/k8s/grafana-planner-dashboard-configmap.yaml

2. Expose the Grafana service using a NodePort for quick testing:

$ kubectl patch svc prometheus-grafana \
    -n monitoring \
    -p '{"spec": {"type": "NodePort"}}'

NodePort is for testing only. For production deployments with secure external access, configure Gateway API with TLS encryption to expose Grafana with HTTPS ingress and certificate management.

3. Get the NodePort assigned to Grafana:

$ kubectl get svc prometheus-grafana -n monitoring -o jsonpath='{.spec.ports[0].nodePort}'; echo

4. Retrieve the Grafana admin password:

$ kubectl get secret prometheus-grafana -n monitoring -o jsonpath='{.data.admin-password}' | base64 -d; echo

5. Access Grafana in your browser. Replace NODE_IP with your cluster node's IP address and NODE_PORT with the port from the previous step:

http://NODE_IP:NODE_PORT

Log in with username admin and the password retrieved in the previous step, then navigate to Dashboards → Dynamo Planner Dashboard to view planner metrics.

12. Monitor Automatic Scaling

The SLA Planner continuously monitors request rates, input/output sequence lengths, TTFT, and ITL metrics from Prometheus, then adjusts prefill and decode worker replicas every adjustment interval (30 seconds in this configuration) to meet SLA targets.

Understanding Planner Behavior

As your application receives inference requests, the planner:

Collects Metrics: Gathers request rates, sequence lengths, and latency metrics from the Dynamo frontend via Prometheus.
Predicts Load: Uses the configured load predictor (constant, ARIMA, Kalman, or Prophet) to forecast future traffic patterns.
Calculates Requirements: Determines optimal worker counts needed to meet TTFT and ITL SLA targets based on predicted load.
Scales Workers: Increases or decreases prefill and decode worker replicas by updating the DynamoGraphDeployment.
Applies Corrections: Adjusts predictions based on observed performance versus expected performance using correction factors.

The dashboard visualizes worker counts, cumulative GPU-hours consumed, observed request/TTFT/ITL metrics, load predictions, correction factors, and a timeline of scaling decisions. Use the Namespace dropdown to filter metrics for your specific deployment namespace (dynamo-system in this guide).

Monitor planner logs:

$ kubectl logs -n ${NAMESPACE} -l app.kubernetes.io/name=vllm-disagg-0-planner,app.kubernetes.io/part-of=vllm-disagg --tail=50 -f

2026-02-28T00:01:53.952354Z  INFO planner_core.run: New adjustment interval started!
2026-02-28T00:01:53.962025Z  INFO planner_core.observe_metrics: Observed num_req: 0.00 isl: 0.00 osl: 0.00
2026-02-28T00:01:53.962037Z  INFO planner_core.observe_metrics: Observed ttft: 0.00ms itl: 0.00ms
2026-02-28T00:01:53.962463Z  INFO planner_core.predict_load: Predicted load: num_req=0.00, isl=0.00, osl=0.00
2026-02-28T00:01:53.962592Z  INFO planner_core._compute_replica_requirements: Predicted number of engine replicas: prefill=1, decode=1
2026-02-28T00:01:53.966200Z  INFO kubernetes_connector.set_component_replicas: prefill component VllmPrefillWorker already at desired replica count 1, skipping

Press Ctrl+C to stop following the logs.

13. Understanding Load Predictors

The SLA Planner uses load predictors to forecast future request patterns and proactively scale resources. Choose from four prediction models based on your workload's traffic patterns.

Constant — assumes the next interval's load equals the current load; use for stable workloads with long adjustment intervals.

planner:
  loadPredictor: constant

ARIMA — uses auto-ARIMA to fit optimal model parameters for time-series data with trends and seasonality.

planner:
  loadPredictor: arima
  loadPredictorLog1p: true

Kalman — provides fast online forecasting with smooth adaptation using a local linear trend Kalman filter.

planner:
  loadPredictor: kalman
  kalmanQLevel: 0.1
  kalmanQTrend: 0.01
  kalmanR: 1.0

Prophet — handles complex seasonal patterns and trend changes using Facebook's Prophet model.

planner:
  loadPredictor: prophet
  prophetWindowSize: 1000
  loadPredictorLog1p: true

Next Steps

Tune plannerMaxGpuBudget and plannerAdjustmentInterval for your real traffic patterns instead of the fast demo values used here.
Swap in ARIMA, Kalman, or Prophet load predictors once you have enough traffic history to evaluate forecasting accuracy.
Put Gateway API with TLS in front of the frontend and Grafana services before exposing either outside your cluster.
Try a different backend (SGLang or TensorRT-LLM) and GPU system combination from the AI Configurator tables to compare profiling results.

For the full guide with additional tips, visit the original article on Vultr Docs.

Creating Remote MCP Server with MCP Proxy

Sanskriti Harmukh — Thu, 29 Oct 2026 17:05:59 +0000

The Model Context Protocol (MCP) is a standard for organizing contextual data used by Large Language Models (LLMs). Instead of relying only on plain prompts, MCP structures key information — like user identity, goals, memory, and tools — so models can act more consistently across sessions, apps, and environments. This guide walks through running a sample MCP server built with FastMCP, backed by an SQLite database, and bridging it to your local Claude Desktop application using a local mcp-proxy. By the end, you'll have a remote MCP server exposing natural-language-powered database endpoints that Claude Desktop can query directly.

1. Get Started Right Away

The code for the MCP server and the sample SQLite database is available in this GitHub repository. To set up the server remotely, follow the steps below in your system terminal.

1. Deploy an Ubuntu server.

2. Clone the GitHub repository:

$ git clone https://github.com/vultr-marketing/code-samples.git

3. Navigate into the mcp_sqlite_sse directory:

$ cd code-samples/mcp/mcp_sqlite_sse

4. Create a .env file:

$ nano .env

5. Add the following variables to the file:

DB_PATH=sample.db
MCP_PORT=8080
READ_ONLY=true

DB_PATH: Path to your SQLite database file.
MCP_PORT: Port used by the MCP server (not used in stdio mode, but good to define).
READ_ONLY: Set to true to block insert/update/delete queries for safety.

Save and close the file.

6. Install dependencies:

$ pip3 install -r requirements.txt

7. Allow incoming connections to port 8080:

$ ufw allow 8080

8. Run the MCP server:

$ python3 server.py

2. Understand the Sample MCP Server

The server script launches a Model Context Protocol (MCP) server using FastMCP and connects it to a local SQLite database. It enables structured interaction with the database using natural language, typically via an LLM interface.

Transport Layer `http` with Server-Sent Events (SSE)

The server uses the http transport layer to communicate over standard web protocols, which is ideal for remote deployment on any cloud instance. It supports Server-Sent Events (SSE), a feature that enables real-time, streamed responses from the server to your local Claude Desktop app via mcp-proxy.

SSE is a core part of live interaction between Claude and your remote MCP server. It ensures that streamed responses (like query results or multi-step outputs) arrive smoothly and in real-time. This design allows Claude Desktop to interact with your database seamlessly, as if the server were running locally. The SSE implementation is lightweight and handled within the FastAPI-based backend exposed by FastMCP.

3. Use Claude Desktop to Interact

Download the Claude Desktop application. It automatically detects MCP servers defined in its configuration file and makes them accessible for use within any conversation.

1. Install the mcp-proxy dependency on your local system:

$ uv tool install mcp-proxy

2. Get the path to the installed dependency:

$ where mcp-proxy

Copy the path to be used later.

3. Start the Claude Desktop application.

4. Locate the settings option in the application.

5. Select Developer settings.

6. Click Edit Config.

7. Add the following configuration snippet to your Claude Desktop config file:

{
    "mcpServers": {
        "remote-fastmcp": {
            "command": "<MCP_PROXY_PATH>",
            "args": [
                "http://<SERVER_IP>:8080/sse"
            ],
            "env": {
                "API_ACCESS_TOKEN": ""
            }
        }
    }
}

8. Once the new configuration is in place, restart the Claude Desktop application.

9. To confirm the server is running, go to the Developer settings in Claude Desktop and check if the status next to the JSON file shows as running.

10. Confirm the MCP server tools are available to the application.

Ask Questions and Perform Operations

You can run interactive queries by chatting naturally. Using the available tools, the LLM translates your requests into SQL queries, executes them on the sample database, and responds in plain language.

The data returned is sample data used for demonstration purposes and may differ from actual data. The LLM also displays the database queries it is executing and the tools it is using to retrieve the data.

Next Steps

Switch READ_ONLY to false once you're comfortable letting the LLM run write queries, and add stricter input validation first.
Front the MCP server with TLS and authentication before exposing it beyond local testing.
Swap the SQLite backend for a networked database if multiple clients need concurrent access.
Explore chaining additional MCP tools to build multi-step, multi-agent workflows.

For the full guide with additional tips, visit the original article on Vultr Docs.

Setting Up Firewall Policies using Iptables

Sanskriti Harmukh — Thu, 29 Oct 2026 17:05:37 +0000

Iptables is a built-in command-line utility that performs packet filtering using the Linux kernel's Netfilter firewall framework. It controls incoming and outgoing network traffic by matching packets against chain rules, using a hierarchical format of tables, chains, and rules. This guide walks through setting up basic traffic filtering rules with target decisions to accept, drop, or reject network packets, plus NAT, logging, and persisting the rules across reboots. By the end, you'll have a working set of iptables firewall policies controlling inbound, outbound, and forwarded traffic on your server.

Prerequisites

A Linux server to use as the workstation.
Access to the server using SSH as a non-root user with sudo privileges.

1. Set Up Firewall Policies

Iptables can filter network packets based on the target table and chain rules. Below are the main tables referenced by iptables.

Filter Table: Contains packet filtering rules that either allow or deny packets to continue to the intended destination.
NAT Table: Contains network packet modification rules that translate specific source addresses to your server network address for forwarding purposes.
Raw Table: Enables access to network packets before the Linux kernel state tracking process.
Security Table: Sets the internal host SELinux security context on network packets.
Mangle Table: Contains rules that alter network packet headers and information such as the time to live (TTL) value.

To configure firewall policies, iptables uses the following built-in chain rules to filter network traffic.

INPUT: Captures incoming network packets on the server. Rules for incoming traffic.
OUTPUT: Captures outgoing network packets.
FORWARD: Forwards network packets routed within the server.

1. View all available iptables rules on the server:

$ sudo iptables -L

Output:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Follow the sections below to set up example firewall policies using iptables.

Allow Incoming Network Requests

1. Allow connection requests to the loopback interface 127.0.0.1:

$ sudo iptables -A INPUT -i lo -j ACCEPT

The above rule enables incoming connection requests to the localhost loopback interface. Within the command:

-A: Adds the rule to the filter table INPUT chain.
-i lo: Applies the rule to the loopback (lo) interface.
-j ACCEPT: Accepts matching network packets without any extra processing.

2. Allow already established and two-way network connections on the server:

$ sudo iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

The above rule accepts incoming network requests to already established connections and related connections in the form of two-way traffic.

3. Allow incoming connections to a specific network port. For example, allow incoming SSH connection requests to the server TCP port 22 from your public IP address subnet 192.0.2.0/30:

$ sudo iptables -A INPUT -p tcp -s 192.0.2.0/30 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

4. Allow incoming connections from one network interface to another. For example, allow network requests from the enp1s0 interface to the enp8s0 interface:

$ sudo iptables -A FORWARD -i enp1s0 -o enp8s0 -j ACCEPT

The above command forwards connection requests from one interface to another. However, additional static routing or NAT processing is required to route connections between hosts on the different networks.

Allow Outgoing Network Requests

1. Allow all outgoing network traffic from the server without any port or address restrictions:

$ sudo iptables -A OUTPUT -j ACCEPT

2. Allow outgoing network traffic from the loopback interface 127.0.0.1:

$ sudo iptables -A OUTPUT -o lo -j ACCEPT

3. Allow established outgoing network connections that match an already established incoming connection:

$ sudo iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

Block IP Addresses and Network Requests

1. Block IP network connections that originate from a specific IPv4 address. For example, 192.0.2.50:

$ sudo iptables -A INPUT -s 192.0.2.50 -j DROP

The above command blocks the network IP 192.0.2.50 from accessing any resources on the server.

2. Block network connections to a specific server interface. For example, block the IP 192.0.2.30 from accessing the internal enp8s0 interface in any way:

$ sudo iptables -A INPUT -i enp8s0 -s 192.0.2.30 -j DROP

3. Block IP access to specific network ports from a specific address range. For example, 10.10.10.0/24:

$ sudo iptables -A INPUT -p tcp -m multiport --dports 22,5901 -s 10.10.10.0/24 -j DROP

4. Block all incoming network requests that don't match any allowed rules:

$ sudo iptables -A INPUT -j DROP

Delete iptables Rules

Depending on your server's network requirements, you can delete specific iptables rules or modify existing entries to match your needs. For example, if a specific IP address no longer needs to be blocked, you can delete that rule.

1. View the available iptables rules and identify the target rule to delete:

$ sudo iptables -L

2. Append the -D option instead of -A on your original iptables rule to delete the target entry. For example, delete the IP blocking rule for the host address 192.0.2.50:

$ sudo iptables -D INPUT -s 192.0.2.50 -j DROP

2. Enable NAT and Port Forwarding

1. Enable NAT resolution through the public interface:

$ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

The above NAT rule translates all network requests to the outbound interface's IP address — for example, hosts on an internal network route to external networks using that interface's IP. Within the above command:

-t nat: Applies the rule to the NAT table.
-A POSTROUTING: Appends the rule to the POSTROUTING chain within the NAT table.
-o eth0: Sets the target network interface to translate requests.
-j MASQUERADE: Enables modification of the source IP address to match the external interface IP.

2. Forward incoming traffic on a given port to an internal interface. For example, forward traffic arriving on the enp8s0 interface:

$ sudo iptables -t filter -A PREROUTING -i enp8s0 -p tcp --dport 8080 -j ACCEPT

3. Forward traffic from a specific port to a destination IP address using dynamic NAT:

$ sudo iptables -t nat -A PREROUTING -i enp8s0 -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.100

3. Log Iptables Rules

1. Log all dropped network packets for debugging purposes with the prompt Dropped iptables packets:

$ sudo iptables -A INPUT -j LOG --log-prefix "Dropped iptables packets:"

2. Log all unknown network packets with the prompt Unknown network packets::

$ sudo iptables -A INPUT -j LOG --log-prefix "Unknown network packets:"

3. View the system log file /var/log/syslog to verify the iptables log entries that match your rules:

$ sudo cat /var/log/syslog

4. Permanently Save Iptables Rules

1. Install the iptables-persistent package:

$ sudo apt install iptables-persistent

2. Save the iptables rules:

$ sudo netfilter-persistent save

Next Steps

Review your full ruleset with sudo iptables -L -v -n and remove any overly broad ACCEPT/DROP rules before relying on this in production.
Pair iptables with fail2ban for automated blocking of repeated failed login attempts.
Consider nftables if you're on a newer distribution, since it's the long-term successor to iptables.
Document your chain order — rule order matters, since iptables evaluates rules top-down per chain.

For the full guide with additional tips, visit the original article on Vultr Docs.

Building a PyTorch Container Image

Sanskriti Harmukh — Thu, 29 Oct 2026 17:05:13 +0000

PyTorch is a flexible machine learning library for building deep learning models that can perform a wide range of tasks such as image recognition and language processing. This guide walks through cloning the PyTorch source repository, building a container image for either CPU or GPU systems, and pushing the finished image to a container registry. By the end, you'll have a custom PyTorch container image built from source and published to a registry, ready to pull into any Docker-compatible environment.

Prerequisites

A server with Docker installed (a GPU-enabled server with the NVIDIA Container Toolkit if you're building the GPU image).
Access to the server using SSH as a non-root user with sudo privileges.
Start the Docker service.
```
$ sudo systemctl start docker
```
Add the non-root user to the Docker group. For example, linuxuser.
```
$ sudo usermod -aG docker linuxuser
```
Switch to the user:
```
$ su - linuxuser
```

1. Set Up the Server

1. Create a new directory to store your PyTorch project files:

$ mkdir llama-project

2. Switch to the directory:

$ cd llama-project

3. Clone the PyTorch project repository using Git:

$ git clone https://github.com/pytorch/pytorch

4. List all files and verify that a new pytorch directory is available:

$ ls

5. Switch to the pytorch project directory:

$ cd pytorch

6. List all directory files and verify the available Dockerfile resources:

$ ls -a

The PyTorch project directory includes the following Dockerfile resources:

Dockerfile: Contains the PyTorch build context for CPU systems.
docker.makefile: Contains advanced GPU build context and image automation directives with support for custom dependency packages.

Use these resources in the next sections to build a CPU or GPU system container image.

2. Build a PyTorch Container Image for CPU Systems

Follow the steps below to build a new PyTorch container image for CPU systems using the Dockerfile resource on your server.

1. Build a new PyTorch container image using the Dockerfile resource. Replace pytorch-image with your desired image name:

$ docker build -f Dockerfile -t pytorch-image .

2. View all Docker images and verify that your new PyTorch image is available:

$ docker images

Output:

REPOSITORY     TAG                                                   IMAGE ID       CREATED       SIZE
pytorch-image  latest                                                d3674f1db4d5   2 hours ago   11.9GB

3. Build a PyTorch Container Image for GPU Systems

Follow the steps below to build a new PyTorch container image for GPU systems using docker.Makefile, which contains the CUDA dependency build context compatible with NVIDIA GPU servers.

1. Build a new PyTorch container image for GPU using the docker.Makefile:

$ docker build -f Dockerfile -t pytorch-image .

Wait at least 2 hours for the build process to complete. When successful, your output should look like the one below:

#29 29224.1 copying torch/include/ATen/ops/_sparse_coo_tensor_with_dims_ops.h -> build/lib.linux-x86_64-cpython-310/torch/include/ATen/ops
#29 29224.1 copying torch/include/ATen/ops/absolute_compositeimplicitautograd_dispatch.h -> build/lib.linux-x86_64-cpython-310/torch/include/ATen/ops
#29 29224.1 copying torch/include/ATen/ops/gradient_ops.h -> build/lib.linux-x86_64-cpython-310/torch/include/ATen/ops
#29 29224.1 copying torch/include/ATen/ops/crow_indices_compositeexplicitautograd_dispatch.h -> build/lib.linux-x86_64-cpython-310/torch/include/ATen/ops
#29 29224.1 copying torch/include/ATen/ops/isinf.h -> build/lib.linux-x86_64-cpython-310/torch/include/ATen/ops
#29 29224.1 copying torch/include/ATen/ops/_fore
#29 29224.1 [output clipped, log limit 2MiB reached]
#29 29235.3 warning: no previously-included files matching '*.o' found anywhere in distribution
#29 29235.4 warning: no previously-included files matching '*.dylib' found anywhere in distribution
#29 29235.7 warning: no previously-included files matching '*.swp' found anywhere in distribution
#29 DONE 29239.6s

#30 [dev 1/1] COPY --from=build /opt/conda /opt/conda
#30 DONE 10.8s

#31 exporting to image
#31 exporting layers
#31 exporting layers 41.0s done
#31 writing image sha256:d3674f1db4d5e9585a5e5b64a0cdfcb0c7d312358e267000e23b6fa9d8e7e917 done
#31 naming to docker.io/root/pytorch:v1.8.0-rc1-38416-g4dc160864b3-cuda12.1-cudnn8-devel done
#31 DONE 41.0s

2. View all Docker images on the server and verify that a new root/pytorch image is available:

$ docker images

Output:

REPOSITORY     TAG                                                   IMAGE ID       CREATED       SIZE
root/pytorch   v1.8.0-rc1-38416-g4dc160864b3-cuda12.1-cudnn8-devel   d3674f1db4d5   3 hours ago   20.9GB

3. Verify the PyTorch GPU image's target CUDA version and confirm your system uses that driver version or higher:

$ cat docker.Makefile | grep CUDA_VERSION

Output:

CUDA_VERSION_SHORT       ?= 12.1
CUDA_VERSION             ?= 12.1.1
BASE_DEVEL                = nvidia/cuda:$(CUDA_VERSION)-cudnn$(CUDNN_VERSION)-devel-ubuntu22.04

Based on the above output, NVIDIA GPU servers with CUDA version 12.1 or higher can run your PyTorch GPU container image.

4. Upload the PyTorch Container Image to a Container Registry

1. Open your container registry's management panel and copy the registry URL, username, and API key (or password) to use when accessing the registry.

2. Switch to your server terminal session and log in to your container registry. Replace your-registry-url, exampleregistry, exampleuser, and registry-password with your actual registry details:

$ docker login https://your-registry-url/exampleregistry -u exampleuser -p registry-password

3. Tag your PyTorch container image with your desired registry tag. For example, tag your PyTorch GPU image ID with a registry repository tag such as your-registry-url/exampleregistry/pytorch-gpu-image:

$ docker tag d3674f1db4d5 your-registry-url/exampleregistry/pytorch-gpu-image

The above command tags the Docker image with container ID d3674f1db4d5 with your registry tag.

4. View all Docker images on the server and verify that the new tagged image is available:

$ docker images

Output:

REPOSITORY           TAG                                                   IMAGE ID       CREATED       SIZE
root/pytorch         v1.8.0-rc1-38416-g4dc160864b3-cuda12.1-cudnn8-devel   d3674f1db4d5   4 hours ago   20.9GB
your-registry-url/exampleregistry/pytorch-gpu-image   latest                 d3674f1db4d5   4 hours ago   20.9GB

5. Push the tagged image to your container registry repository:

$ docker push your-registry-url/exampleregistry/pytorch-gpu-image

6. Open your container registry's management panel and check the repositories list to verify that the new repository is available.

Next Steps

Automate the build and push steps in a CI/CD pipeline so new PyTorch images are rebuilt on every commit.
Pull the image into a Kubernetes cluster or Docker Compose stack to run inference or training workloads.
Trim the final image size with multi-stage builds if you only need the runtime (not the full build toolchain).
Pin the CUDA and cuDNN versions in your Dockerfile to keep builds reproducible across environments.

For the full guide with additional tips, visit the original article on Vultr Docs.

Building Serverless APIs with Kotlin Ktor and Coroutines

Sanskriti Harmukh — Thu, 22 Oct 2026 23:24:17 +0000

Modern serverless platforms demand fast startup times, low resource overhead, and efficient concurrency. Kotlin, with its modern syntax and coroutine-based concurrency, and Ktor, its lightweight asynchronous web framework, provide an ideal combination for building high-performance serverless APIs. This guide demonstrates how to build a Product Catalog CRUD API using Kotlin and Ktor, structure a coroutine-driven application, handle concurrent requests efficiently, and package it for deployment across cloud providers in fully serverless or containerized environments. By the end, you'll have a working CRUD API, hardened for external calls, packaged as a portable JAR ready for serverless or container deployment.

Prerequisites

Before you begin:

Have access to an Ubuntu 24.04 based server as a non-root user with sudo privileges.
Install JDK 17+ (OpenJDK recommended).
Use the project's Gradle wrapper (./gradlew). Installing Gradle system-wide is optional.

Setting Up Your Development Environment

1. Verify Java and Gradle:

$ java -version
$ ./gradlew -v || echo "Gradle wrapper will be generated by Ktor project"

2. Generate a new project at start.ktor.io with:

Group: io.demo
Artifact: product-api
Package: io.demo.productcatalog
Dependencies: Server Core, Netty, Routing, Content Negotiation (kotlinx-serialization)

3. Unpack and open the project:

$ unzip product-api.zip -d product-api
$ cd product-api

4. Run the template to confirm the toolchain:

$ ./gradlew run

In another terminal:

$ curl -s http://localhost:8080/ || true

5. Ensure JSON serialization is enabled (add if missing):

// build.gradle.kts
dependencies {
   implementation("io.ktor:ktor-server-core-jvm")
   implementation("io.ktor:ktor-server-netty-jvm")
   implementation("io.ktor:ktor-server-content-negotiation-jvm")
   implementation("io.ktor:ktor-serialization-kotlinx-json-jvm")
   implementation("io.ktor:ktor-server-config-yaml-jvm")
   implementation("io.ktor:ktor-server-call-logging-jvm")
   implementation("io.ktor:ktor-server-compression-jvm")
   implementation("io.ktor:ktor-server-caching-headers-jvm")
   implementation("io.ktor:ktor-server-request-timeout-jvm")
   implementation("io.ktor:ktor-server-metrics-micrometer-jvm")
   implementation("ch.qos.logback:logback-classic:1.5.6")
}

6. Wire the plugin in the application:

// src/main/kotlin/io/demo/productcatalog/Application.kt
install(ContentNegotiation) { json() }

Understanding Ktor and Coroutines for Serverless

Ktor uses non-blocking I/O and Kotlin coroutines to handle high concurrency with low memory overhead, ideal for short-lived, autoscaled serverless workloads.

Event loop + suspending handlers: Handlers suspend on I/O instead of blocking threads, so a few threads serve many requests.
Coroutines vs. threads: Coroutines are lightweight; you can run thousands without the context-switch cost of OS threads.
Structured concurrency: Scope your launches (e.g., call or application scope) to avoid leaks across requests.
Backpressure: Keep endpoints non-blocking; offload CPU-heavy or blocking work to Dispatchers.Default/custom pools.
Cold starts: Trim dependencies and init work; defer heavy setup until first use.

Building Your First Serverless API with Ktor

Build a Product Catalog CRUD API to demonstrate routing, JSON serialization, and coroutine-friendly data access.

1. Create the project structure:

src/
└── main/
    ├── kotlin/io/demo/productcatalog/
    │   ├── Application.kt
    │   ├── Routing.kt
    │   ├── model/Product.kt
    │   └── repository/ProductRepository.kt
    └── resources/
        ├── application.yaml
        └── logback.xml

2. Create the model file at src/main/kotlin/io/demo/productcatalog/model/Product.kt:

@Serializable
data class Product(
   val id: String = UUID.randomUUID().toString(),
   val name: String,
   val price: Double,
   val stock: Int
)

@Serializable
data class ProductCreate(
   val name: String,
   val price: Double,
   val stock: Int
)

3. Create the in-memory repository file (simulated async) at src/main/kotlin/io/demo/productcatalog/repository/ProductRepository.kt:

object ProductRepository {
    private val products = mutableListOf<Product>()

    init {
        products += Product(name = "Laptop", price = 1200.0, stock = 20)
        products += Product(name = "Smartphone", price = 800.0, stock = 10)
        products += Product(name = "Headphones", price = 150.0, stock = 30)
    }

    suspend fun all(): List<Product> {
        delay(50)
        return products.toList()
    }

    suspend fun find(id: String): Product? {
        delay(50)
        return products.find { it.id == id }
    }

    suspend fun add(product: Product): Product {
        delay(50)
        products.add(product)
        return product
    }

    suspend fun update(id: String, product: Product): Product? {
        delay(50)
        val idx = products.indexOfFirst { it.id == id }
        return if (idx != -1) product.copy(id = id).also { products[idx] = it } else null
    }

    suspend fun delete(id: String): Boolean {
        delay(50)
        return products.removeIf { it.id == id }
    }
}

4. Create the routing configuration file at src/main/kotlin/io/demo/productcatalog/Routing.kt:

fun Application.configureRouting() {
    routing {
        get("/") { call.respond(mapOf("message" to "Product Catalog API")) }
        get("/ping") { call.respond(mapOf("message" to "pong")) }

        get("/products") { call.respond(ProductRepository.all()) }

        get("/products/{id}") {
            val id = call.parameters["id"] ?: return@get call.respond(HttpStatusCode.BadRequest)
            ProductRepository.find(id)?.let { call.respond(it) }
                ?: call.respond(HttpStatusCode.NotFound)
        }

        post("/products") {
            val dto = call.receive<ProductCreate>()
            if (dto.name.isBlank() || dto.price < 0 || dto.stock < 0) {
                return@post call.respond(HttpStatusCode.BadRequest, mapOf("error" to "Invalid product: name must be non-blank, price and stock ≥ 0"))
            }
            val saved = ProductRepository.add(Product(name = dto.name, price = dto.price, stock = dto.stock))
            call.respond(HttpStatusCode.Created, saved)
        }

        put("/products/{id}") {
            val id = call.parameters["id"] ?: return@put call.respond(HttpStatusCode.BadRequest)
            val dto = call.receive<ProductCreate>()
            if (dto.name.isBlank() || dto.price < 0 || dto.stock < 0) {
                return@put call.respond(HttpStatusCode.BadRequest, mapOf("error" to "Invalid product: name must be non-blank, price and stock ≥ 0"))
            }
            val updated = ProductRepository.update(id, Product(name = dto.name, price = dto.price, stock = dto.stock))
            updated?.let { call.respond(it) } ?: call.respond(HttpStatusCode.NotFound)
        }

        delete("/products/{id}") {
           val id = call.parameters["id"] ?: return@delete call.respond(HttpStatusCode.BadRequest)
            if (ProductRepository.delete(id)) call.respond(HttpStatusCode.NoContent)
            else call.respond(HttpStatusCode.NotFound)
        }
    }
}

5. Edit the application file with the following module configuration in src/main/kotlin/io/demo/productcatalog/Application.kt:

fun Application.module() {
    install(ContentNegotiation) { json() }
    configureRouting()
}

This enables JSON serialization and registers the routing configuration.

6. Run the application using Gradle:

$ ./gradlew run

Output:

> Task :run
2025-10-13 15:19:55.869 [main] INFO  Application - Autoreload is disabled because the development mode is off.
2025-10-13 15:19:56.298 [main] INFO  Application - Application started in 0.774 seconds.
2025-10-13 15:19:56.629 [DefaultDispatcher-worker-1] INFO  Application - Responding at http://0.0.0.0:8080
<==========---> 83% EXECUTING [19m 10s]
> :run

7. Verify the base routes:

$ curl http://localhost:8080/
$ curl http://localhost:8080/ping

Output:

{"message":"Product Catalog API"}
{"message":"pong"}

Handling Concurrency and Performance

Ktor serves each request on a lightweight coroutine, so a handful of threads can handle heavy concurrency. Tune the app to stay non-blocking, predictable, and fast.

Keep handlers non-blocking. Use withContext(Dispatchers.IO) for blocking work (file I/O, JDBC) so you don't stall the event loop.
```
suspend fun readFile(path: Path): String =
    withContext(Dispatchers.IO) { Files.readString(path) }
```

Use structured concurrency in routes. Launch child coroutines in a scope and await() them together. If one fails, Ktor cancels siblings and the request.

get("/report") {
    coroutineScope {
        val a = async { service.fetchA() }   // suspend fun
        val b = async { service.fetchB() }
        call.respond(mapOf("a" to a.await(), "b" to b.await()))
    }
}

Right-size dispatchers (only when needed). Let Ktor manage event loops. If you must isolate heavy I/O/CPU work, bound the pool and close it on shutdown.
```
val ioPool = Executors.newFixedThreadPool(8).asCoroutineDispatcher()
environment.monitor.subscribe(ApplicationStopped) { ioPool.close() }
```
Remove artificial delays in production. Replace delay() in repositories with real async I/O (database, HTTP client).

Add low-cost server features. Compression, caching headers, and request timeouts improve latency and protect the app.

fun Application.module() {
    install(ContentNegotiation) { json() }
    install(Compression) { gzip() }
    install(CachingHeaders) {
        options { CachingOptions(CacheControl.MaxAge(maxAgeSeconds = 60)) }
    }
    install(RequestTimeout) { requestTimeoutMillis = 5_000 }
    configureRouting()
}

Integrating External Services

Connect to databases and APIs with suspendable, time-bounded calls. Add retries sparingly, log context, and protect upstreams.

Ktor HTTP Client (timeouts, retries, JSON)

Configure a resilient Ktor HTTP client with JSON, timeouts, and limited retries.

val http = HttpClient(CIO) {
    expectSuccess = true

    install(ContentNegotiation) { json() }

    install(HttpTimeout) {
        requestTimeoutMillis = 2_000
        connectTimeoutMillis = 1_000
        socketTimeoutMillis  = 2_000
    }

    // Ktor's retry feature (Ktor 2.x)
    install(HttpRequestRetry) {
        retryOnServerErrors(maxRetries = 2)
        exponentialDelay(base = 200, maxDelayMs = 1_000)
        // Optionally retry on specific exceptions:
        retryIf { _, cause -> cause is HttpRequestTimeoutException }
        retryOnExceptionIf { _, cause -> cause is java.io.IOException }
    }

    defaultRequest {
        header("Accept", "application/json")
    }
}

Add client dependencies to your build file.

// build.gradle.kts
dependencies {
    implementation("io.ktor:ktor-client-core-jvm")
    implementation("io.ktor:ktor-client-cio-jvm")
    implementation("io.ktor:ktor-client-content-negotiation-jvm")
    implementation("io.ktor:ktor-serialization-kotlinx-json-jvm")
    implementation("io.ktor:ktor-client-http-timeout-jvm")
    implementation("io.ktor:ktor-client-retry-jvm")
    testImplementation("io.ktor:ktor-client-mock-jvm")
}

Close the shared client on shutdown to prevent resource leaks.

environment.monitor.subscribe(ApplicationStopped) { http.close() }

Inject the client and base URL for testability. Example with a repository and a MockEngine-based test setup:

class PriceRepository(
    private val client: HttpClient,
    private val baseUrl: String
) {
    suspend fun fetchPrices(): List<Price> = client.get("$baseUrl/prices").body()
}

// wiring (e.g., in Application.module)
val pricesBaseUrl: String = environment.config.propertyOrNull("app.services.prices.baseUrl")?.getString()
    ?: System.getenv("PRICES_BASE_URL")
    ?: "https://api.example.com"
val priceRepository = PriceRepository(http, pricesBaseUrl)

// test setup
val mockClient = HttpClient(MockEngine) {
    engine {
        addHandler { request ->
            if (request.url.encodedPath.endsWith("/prices")) {
                respond(
                    content = "[{\"sku\":\"A\",\"value\":10.0}]",
                    headers = headersOf("Content-Type" to listOf("application/json"))
                )
            } else error("Unhandled ${'$'}{request.url}")
        }
    }
    install(ContentNegotiation) { json() }
}
val mockRepo = PriceRepository(mockClient, "https://mock.local")

Call the client from a repository; keep functions suspend, add per-call timeouts if a dependency is flaky.

@Serializable data class Price(val sku: String, val value: Double)

object PriceService {
    suspend fun fetchPrices(): List<Price> =
        http.get("https://api.example.com/prices").body()
}

Per-call timeout override:

suspend fun fetchPricesFast(): List<Price> =
    http.get("https://api.example.com/prices") {
        timeout { requestTimeoutMillis = 1_000 }
    }.body()

Minimal "circuit breaker" guard (lightweight)

If an upstream often times out, short-circuit for a brief window. Keep it simple without extra libs.

class SimpleBreaker(
    private val threshold: Int = 5,
    private val openMillis: Long = 5_000
) {
    @Volatile private var failures = 0
    @Volatile private var openedAt = 0L

    fun allow(): Boolean =
        if (System.currentTimeMillis() - openedAt > openMillis) true else failures < threshold

    fun recordSuccess() { failures = 0; openedAt = 0 }
    fun recordFailure() {
        failures++
        if (failures >= threshold) openedAt = System.currentTimeMillis()
    }
}

val breaker = SimpleBreaker()

suspend fun guardedPrices(): List<Price> {
    if (!breaker.allow()) return emptyList() // fallback
    return try {
        val data = PriceService.fetchPrices()
        breaker.recordSuccess()
        data
    } catch (e: Exception) {
        breaker.recordFailure()
        emptyList() // degrade gracefully
    }
}

Database integration tips (JDBC/JPA/R2DBC)

JDBC/JPA: treat calls as blocking; wrap in withContext(Dispatchers.IO). Keep pools small but sufficient.
R2DBC / async drivers: prefer truly non-blocking drivers when available.
Set short query timeouts and fail fast on connection errors.

suspend fun findProductById(id: String): Product? =
    withContext(Dispatchers.IO) {
        dataSource.connection.use { conn ->
            conn.prepareStatement("SELECT ... WHERE id = ?").use { ps ->
                ps.queryTimeout = 2 // seconds
                ps.setString(1, id)
                ps.executeQuery().use { rs -> /* map to Product */ null }
            }
        }
    }

Observability (logs, metrics, traces)

Log request IDs: propagate a X-Request-ID header.
Emit timing metrics (Micrometer) around integrations.
Sample traces on external calls (OpenTelemetry) for latency hotspots.

install(CallLogging) {
    mdc("requestId") { call.request.headers["X-Request-ID"] ?: UUID.randomUUID().toString() }
}

Hardening checklist

Time-box every external call (client + per-call timeouts).
Add bounded retries with exponential backoff (no infinite retries).
Use fallback/cached responses for non-critical paths.
Validate and sanitize all inbound/outbound payloads.
Keep secrets in environment variables or a secret store; never hard-code.

Deploying and Monitoring Across Cloud Providers

Ship a portable artifact, run it the same way everywhere, and expose health/metrics for hands-off ops.

Package a single, portable JAR

Serverless/container platforms don't resolve Gradle deps, so build a fat JAR.

1. Add the following content in libs.versions.toml:

[plugins]
shadow = { id = "com.github.johnrengelman.shadow", version = "8.1.1" }

2. Add the following content in build.gradle.kts:

plugins {
    alias(libs.plugins.kotlin.jvm)
    alias(libs.plugins.kotlin.plugin.serialization)
    alias(libs.plugins.ktor)
    alias(libs.plugins.shadow)
}

application {
    mainClass.set("io.demo.productcatalog.ApplicationKt")
}

tasks {
    shadowJar {
        archiveBaseName.set("product-api")
        archiveClassifier.set("")
        archiveVersion.set("")
    }
}

3. Build and smoke-test locally:

$ ./gradlew shadowJar
$ java -jar build/libs/product-api-all.jar

Make the app cloud-friendly (port, health, graceful shutdown)

1. Configure the application port and external services in resources/application.yaml:

ktor:
  deployment:
    port: ${PORT:8080}   # use env var PORT if provided
  application:
    modules:
      - io.demo.productcatalog.ApplicationKt.module
app:
  services:
    prices:
      baseUrl: ${PRICES_BASE_URL:https://api.example.com}

This configuration allows the application to bind to a dynamic port provided by the cloud platform and defines an external service base URL through environment variables.

2. Add lightweight ops features:

fun Application.module() {
    install(ContentNegotiation) { json() }
    install(CallLogging)
    install(Compression) { gzip() }
    // optional timeouts to avoid hung requests
    install(RequestTimeout) { requestTimeoutMillis = 5_000 }

    routing {
        get("/ready") { call.respond(mapOf("status" to "ok")) }   // readiness
        get("/live") { call.respond(mapOf("status" to "ok")) }    // liveness
    }
    configureRouting()
}

These changes make the application suitable for cloud platforms by supporting dynamic port binding, health probes for orchestration systems, request logging, response compression, and graceful request timeouts.

Observability: logs, metrics, traces (portable setup)

Structured logs:

install(CallLogging) // keep message rates low, include request ids if available

Prometheus metrics:

// build.gradle.kts: implementation("io.micrometer:micrometer-registry-prometheus:<version>")
val registry = io.micrometer.prometheus.PrometheusMeterRegistry(io.micrometer.prometheus.PrometheusConfig.DEFAULT)
install(io.ktor.server.metrics.micrometer.MicrometerMetrics) { this.registry = registry }

routing { get("/metrics") { call.respondText(registry.scrape()) } }

Advanced Tips for Optimizing Ktor in Serverless Environments

Keep dependencies lean. Every jar adds cold-start time.
Avoid blocking the event loop. Wrap unavoidable blocking in a bounded IO dispatcher.
Warm paths on deploy. Optionally pre-load serializers/config.
Cache smartly. Memoize hot, static reads with short TTLs.
Benchmark routinely. Use wrk/k6 to tune timeouts, thread pools, and memory.

Next Steps

Add authentication/authorization (e.g., JWT) in front of the /products routes.
Swap the in-memory ProductRepository for an async-friendly database driver.
Wire up the Prometheus metrics endpoint and an OpenTelemetry exporter for production tracing.
Load-test the packaged JAR with wrk or k6 to validate timeout and retry settings under concurrency.

For the full guide with additional tips, visit the original article on Vultr Docs.

Using Rsync to Transfer Files in Linux

Sanskriti Harmukh — Thu, 22 Oct 2026 23:23:25 +0000

Rsync is a file transfer tool for transferring and synchronizing files across systems. It's commonly used for backups, file mirroring, and updating files between local directories or remote servers. Rsync reduces data transfer by copying only the differences between the source and destination files, and its speed, flexibility, and extensive options make it a popular choice for system administrators and developers. This guide installs Rsync and walks through using it to perform local and remote file transfers from your workstation. By the end, you'll have transferred and excluded files locally, and synchronized a directory to a remote machine over SSH.

Install Rsync

Rsync is available in the official repositories on most Linux distributions and is often pre-installed.

1. Install Rsync on Ubuntu and Debian using the APT package manager:

$ sudo apt install rsync

2. Install Rsync on FreeBSD using the PKG package manager:

$ sudo pkg install rsync

3. Install Rsync on Arch Linux using the Pacman package manager:

$ sudo pacman -S rsync

4. Install Rsync on Fedora, AlmaLinux, Rocky Linux, and VzLinux using the DNF package manager:

$ sudo dnf install rsync

5. Install Rsync on CentOS using the YUM package manager:

$ sudo yum install rsync

Rsync Command Syntax

Rsync uses the following command syntax.

rsync [OPTION] SRC DEST

Within the command:

[OPTION]: Represents the options or flags passed to the Rsync command.
SRC: The source files and directories you want to synchronize.
- Use USER@HOST:SRC when transferring files remotely over SSH.
DEST: The destination where the files or directories will be synchronized.
- Use USER@HOST:DEST when transferring files remotely over SSH.

Rsync Command Options

The following are the most common Rsync command options:

Option	Long Form	Short Form	Description
Help	`--help`	`-h`	Show Rsync command help
Verbosity	`--verbose`	`-v`	Increase verbosity
	`--quiet`	`-q`	Suppress non-error messages
File Selection	`--archive`	`-a`	Archive mode
	`--recursive`	`-r`	Recurse into directories
	`--relative`	`-R`	Use relative path names
Updates	`--update`	`-u`	Skip files that are newer on the receiver
	`--inplace`		Update destination files in-place
Backups	`--backup`	`-b`	Make backups (see `--suffix` & `--backup-dir`)
	`--backup-dir=DIR`		Make backups into hierarchy based in DIR
Symlinks	`--links`	`-l`	Copy symlinks as symlinks
	`--copy-links`	`-L`	Transform symlink into referent file/dir
Permissions	`--perms`	`-p`	Preserve permissions
Timestamps	`--times`	`-t`	Preserve modification times
Deletion	`--delete`		Delete extraneous files from dest dirs
	`--delete-excluded`		Also delete excluded files from dest dirs
Simulation	`--dry-run`	`-n`	Perform a trial run with no changes made
Remote Shell	`--rsh=COMMAND`	`-e`	Specify the remote shell to use
Size Control	`--max-size=SIZE`		Don't transfer any file larger than `SIZE`
	`--min-size=SIZE`		Don't transfer any file smaller than `SIZE`
Partial Transfer	`--partial`		Keep incomplete transferred files
File Filtering	`--exclude=PATTERN`		Exclude files matching PATTERN
	`--include=PATTERN`		Don't exclude files matching PATTERN
Output Format	`--progress`		Show progress during transfer
	`-P`		Same as `--partial --progress`
	`--human-readable`	`-h`	Output numbers in a human-readable format
Compression	`--compress`	`-z`	Compress file data during the transfer
IP Version	`--ipv4`	`-4`	Prefer IPv4
	`--ipv6`	`-6`	Prefer IPv6

Transfer Files and Directories Using Rsync

Set up a test environment before running the Rsync commands below.

1. Create a directory named rsync-test to work with:

$ mkdir rsync-test

2. Navigate into the newly created directory:

$ cd rsync-test

3. Create three sample files:

$ touch file1 file2 file3

Transfer Local Files

1. Copy file1, file2, and file3 to a new directory named dest. In Rsync, the last argument always represents the destination. Ensure the destination path is correctly specified to prevent accidental overwrites:

$ rsync file1 file2 file3 dest

file1 file2 file3: Source files to copy.
dest: Destination directory where the files will be copied.

2. Verify that the files were copied successfully:

$ ls dest/

Your output should be similar to the one below.

./dest/file1
./dest/file2
./dest/file3

Transfer Local Directories

Rsync does not copy files inside a directory by default. Use the -a flag to enable recursive copying, which enables archive mode, preserving timestamps, permissions, group, owner, and symbolic links.

1. Copy the dest directory you created earlier:

$ rsync -a dest/ dest-copy

-a: Enables archive mode to preserve file attributes while copying recursively.
dest/: The source directory to copy (trailing / means copy contents, not the directory itself. If you omit the trailing /, Rsync copies the entire directory instead of just its contents).
dest-copy: The destination directory.

2. Verify the copy operation:

$ ls dest-copy/

Your output should be similar to the one below. A dest-copy directory is created with the same content as the dest directory.

./dest-copy/file1
./dest-copy/file2
./dest-copy/file3

Exclude Files or Directories Using Rsync

To exclude specific files or directories from being copied, use the Rsync --exclude flag.

1. Copy the contents of the current directory, excluding file2 and all directories that start with dest:

$ rsync -a --exclude 'file2' --exclude 'dest*' . output

-a: Enable archive mode.
--exclude 'file2': Exclude files and directories named file2.
--exclude 'dest*': Exclude files and directories that start with dest.
.: Specify the current directory as the source.
output: The destination directory.

2. Verify the copy operation:

$ ls output/

Your output should be similar to the one below. Notice that the output directory contains only file1 and file3.

./output/file1
./output/file3

Synchronize Data to a Remote Machine Using Rsync

1. Synchronize files and directories to a remote machine:

$ rsync -hazvP --delete --stats . user@192.0.2.1:synced_from_local

-h: Output numbers in human-readable format.
-a: Enables archive mode for preserving metadata.
-z: Compresses data during transfer.
-v: Enables verbose output.
-P: Displays progress and resumes partial transfers.
--delete: Removes files from the destination that no longer exist in the source.
--stats: Provides a detailed summary of the transfer.
.: Specify the current directory as the source.
user@192.0.2.1:synced_from_local: Specify the remote machine as the destination. This consists of three parts:
- user: The username to access the remote machine.
- 192.0.2.1: The IP address of the remote machine.
- synced_from_local: The destination path.

2. Log in to the remote machine using SSH:

$ ssh user@192.0.2.1

3. Verify that the files have been synced:

$ ls synced_from_local/

Output:

synced_from_local/dest-copy/file1
synced_from_local/dest-copy/file2
synced_from_local/dest-copy/file3
synced_from_local/dest/file1
synced_from_local/dest/file2
synced_from_local/dest/file3
synced_from_local/file1
synced_from_local/file2
synced_from_local/file3
synced_from_local/output/file1
synced_from_local/output/file3

Warning on Using the `--delete` Rsync Option

Be cautious when using --delete, as it permanently removes files from the destination if they don't exist in the source. Always perform a dry run first:

$ rsync -a --delete --dry-run SRC DEST

Next Steps

Schedule recurring Rsync jobs with cron to keep a backup directory continuously in sync.
Combine --exclude with a .rsync-filter file to manage more complex exclusion rules.
Use --dry-run as a standard habit before any sync that includes --delete.
Run man rsync for the full list of options and remote-shell configurations.

For the full guide with additional tips, visit the original article on Vultr Docs.