DEV Community: ServerAvatar

How to Fix SSH Connection Refused Error

Meghna Meghwani — Tue, 28 Jul 2026 06:11:08 +0000

You have typed your command, hit Enter, expecting to connect to your server. Instead, you’re greeted with the frustrating SSH Connection Refused error rather than a welcoming shell prompt.

ssh: connect to host your-server port 22: Connection refused

That flat, unhelpful line is one of the most frustrating messages in server management. No explanation. No suggested fix. Just a door slammed in your face.

I have been there more times than I’d like to admit, particularly after spinning up new VPS instances where I’d forgotten to note the custom SSH port, or after a firewall rule I applied broader than intended cut off my own access.

The good news: SSH Connection Refused is almost always fixable in minutes once you know what to check. This guide walks through every real cause I have encountered in practice, with the exact commands that diagnose and resolve each one.

What this guide covers: the meaning behind the error, causes, step-by-step fixes, a prevention checklist, and the FAQs I actually hear from developers.

Who it’s for: anyone managing a Linux server, whether it’s your first VPS or your hundredth.

TL;DR

SSH Connection Refused means the server is actively rejecting your connection attempt
The most common causes: wrong port, service not running, firewall blocking, wrong credentials, and SSH not installed
Most fixes take under 5 minutes from your terminal
Always verify the fix by attempting to reconnect before assuming the problem is solved
Prevention: use non-default ports, configure fail2ban, and restrict SSH to specific IPs

What Does “SSH Connection Refused” Actually Mean?

Let’s be precise, because understanding the mechanics changes how you debug.

“Connection Refused” is TCP’s way of saying: I heard you, but I’m not accepting this connection. The server received your SYN packet, processed it, and sent back a RST (reset) flag. This is fundamentally different from a timeout (where the server never responds at all) or an authentication failure (where the server accepts the connection but rejects your credentials).

In SSH terms, this means the SSH daemon, sshd , either isn’t listening on the port you are targeting, isn’t running at all, or something network-level is intercepting the request before it reaches the daemon.

The practical difference matters: if you see “Connection Refused”, you at least know the server is reachable over the network. That’s useful diagnostic information.

If you want to learn more about how SSH works internally, including its configuration options and authentication process, the official OpenSSH documentation provides detailed explanations.

How to Diagnose SSH Connection Refused

Before fixing anything, verify. The most common mistake I see is jumping to conclusions, changing the SSH port when the problem was the firewall, or reinstalling SSH when the service just needed a restart.

Here’s the diagnostic sequence I follow, in order:

Step 1: Confirm the server is reachable at all

ping -c 3 your-server-ip

If ping fails, you have a network connectivity issue, possibly the server is down, or it’s on an unreachable network. That’s a different problem than Connection Refused.

Step 2: Check if the SSH port is reachable

nc -zv your-server-ip 22
# or if the port is non-standard:
nc -zv your-server-ip 2222

If this shows “Connection refused”, you have confirmation the problem is at the SSH layer.

Step 3: Use SSH verbose mode for more detail

ssh -v username@your-server-ip -p PORT

The -v flag (use -vvv for maximum verbosity) shows exactly where the connection attempt stalls.

This alone often points you directly to the problem.

Read Full Article: https://serveravatar.com/ssh-connection-refused

Linux File Permissions Explained: Read, Write, and Change Permissions

Meghna Meghwani — Sat, 25 Jul 2026 06:28:56 +0000

Linux file permissions are one of the first concepts every Linux user and system administrator needs to master. Every sysadmin has been burned by a permissions mistake at least once. Uploaded a script that won’t run. Moved a file you couldn’t overwrite. Set up a deployment hook that silently failed because the user running it didn’t have write access to the log directory. These aren’t exotic edge cases, they’re the daily friction of working on a Linux system.

Linux file permissions are the gatekeepers of everything that runs on your server. Get them right, and your applications work smoothly, your users can access what they need, and your server stays reasonably secure. Get them wrong, and you’re either locked out of your own files or handing out access like candy.

This guide cuts through the noise. You’ll learn exactly how Linux permission bits work, what each one actually does when you’re logged in, how to read the cryptic output of ls -l, and how to change permissions the right way using both symbolic and numeric chmod. Everything here is written from the perspective of someone who’s spent real hours on actual servers, not just quoting man pages.

TL;DR

Linux has three permission types: Read (r), Write (w), and Execute (x)
Permissions apply to three categories of users: Owner (u), Group (g), and Others (o)
The ls -l command shows permissions in a 10-character string like -rw-r--r--
Use chmod to change permissions, symbolic mode (u+x) or numeric mode (755)
Use chown and chgrp to change ownership
Common pitfalls: execute bit on directories, wrong group ownership, restrictive umask in production

Why Linux Permissions Matter More Than You Think

On a single-user laptop, permissions feel academic. On a server running multiple services, serving web traffic, and handling multiple users? Permissions are load-bearing infrastructure.

When a web server like Nginx runs, it typically operates under its own user, www-data on Ubuntu. The user account must have read permissions for the web root directory in order to serve website files. Your deployment script, running as a deploy user, needs write access to certain directories and execute access to deployment hooks. Your backup cron job, running as root, needs read access to everything but write access only to the backup volume.

Getting any one of these wrong breaks something silently. I’ve seen a Node.js app that kept crashing every night because a cron job was deleting its log directory, and the app didn’t have permission to recreate it. Permissions weren’t on anyone’s radar until the app started failing.

Understanding permissions also matters for security. The difference between chmod 777 and chmod 644 on a configuration file could be the difference between a server that’s yours and a server that’s been compromised. That’s not hyperbole, misconfigured permissions are a documented entry point for a wide range of attacks.

The Three Layers: Owner, Group, Others

Before you can understand what a permission means, you need to know who it’s being applied to. Linux splits access into three layers:

Owner (u)

The user who created the file. On a shared server, each user has their own home directory with files they own. The owner can change permissions on their own files, or take them away from themselves, which is a fun way to lock yourself out of something.

Group (g)

A group is a named collection of users. Instead of granting the same permission to five individual users one by one, you put them in a group and set permissions once. This is how most team-based server access works in practice.

Others (o)

Everyone else, users who aren’t the owner and aren’t in the owning group. “Others” permissions are your last line of defense. They’re what the world gets when someone with no account on your server tries to access your files.

The Three Permission Types Explained

Read (r or 4)

Read permission lets a user view a file’s contents. For a directory, read means listing the directory’s contents, you can see what files and subdirectories exist inside it, but you can’t enter it or access any of those files without additional permissions.

In practice, read on a directory is the permission that ls checks. Without it, ls returns a permission denied error even if you already know the directory exists.

Write (w or 2)

Write permission lets a user modify a file’s contents, add data, truncate it, rewrite it entirely. On a directory, write means you can create, delete, and rename files inside that directory.

Here’s the part that catches people: you need write permission on the directory itself to delete a file, not write permission on the file.

Execute (x or 1)

Execute permission is what makes a file run as a program or script. Without it, trying to run ./script.sh gives you a “permission denied” error, even if you own the file and have full read/write access.

For directories, execute has a different meaning: it allows access to the directory’s metadata and file contents. Without execute on a directory, you can’t cd into it or access any file inside it, even if you have read permission on those individual files.

Read Full Article: https://serveravatar.com/linux-file-permissions

How to Upload Image File in Laravel: Step-by-Step Guide

Meghna Meghwani — Thu, 23 Jul 2026 06:29:44 +0000

Every Laravel project I’ve worked on, whether it’s a client portal, a content management system, or an e-commerce setup, eventually needs one thing: upload image functionality. User avatars, product photos, blog thumbnails, and document attachments all rely on a reliable image upload system. The requirement shows up predictably, yet every time I reach for the documentation, I find myself piecing together bits from half a dozen sources.

Most tutorials cover the happy path. They show you the store() method, they mention enctype="multipart/form-data", and they call it done. But what about the messy parts? What happens when a user uploads a 12MB file and your server chokes? What if the validation rule passes locally but fails on your production VPS because of a misconfigured php.ini? And does your application actually handle filename collisions gracefully, or is it quietly overwriting files?

This guide is the tutorial I wish existed when I first needed to build robust image upload functionality in Laravel. We are going to cover the full picture, from setting up your database schema for image metadata, to building a form with client-side preview, to handling validation edge cases that tutorials skip, to the security considerations that actually matter in production.

TL;DR

Laravel handles image uploads through its filesystem layer, no extra packages needed for basic uploads
Store metadata (not just files) in your database: filename, path, MIME type, size, dimensions
Always validate on the server AND (for UX) on the client, server-side validation is non-negotiable
The storage:link command is still essential for serving files from the public web
Production concerns, PHP limits, disk permissions, filename collisions, are where most tutorials fall short
ServerAvatar’s built-in server management removes the permission and PHP config headaches from your deployment workflow

How Laravel’s File Storage Actually Works

Before we write a single line of code, it helps to understand what actually happens when a file upload reaches a Laravel application. This model will save you hours of debugging later.

When a user submits a multipart form, Laravel wraps the uploaded file in an UploadedFile object. This isn’t just the file data, it carries metadata: original filename, MIME type, file size, temporary path on disk, and more.

Laravel’s official documentation provides a detailed overview of uploaded files, storage disks, and filesystem operations if you want to explore advanced storage features.

Laravel then hands this object to the filesystem layer, which decides where to put the file based on your config/filesystems.php configuration. The two most relevant disks for image uploads are:

public – Files land in storage/app/public. These are accessible directly from the web, but only if you’ve run php artisan storage:link to create a symlink from public/storage to storage/app/public. This is the standard path for user-uploaded content you want publicly served.
local – Files land in storage/app. These are not web-accessible by default, which makes them suitable for files you want to control access to, think documents behind a paywall, or images served through a signed URL.

For most image upload use cases, profile photos, product images, gallery uploads, you will use public with the storage:link symlink. I will focus on that path in this guide.

Database Design: Storing Image Metadata the Right Way

Here’s a mistake I see constantly: they store the uploaded image path as a plain string column on the user or product table, and call it a day. This works until you need to display the image’s dimensions, filter by file size, or track which uploads are causing storage bloat.

Separate your concerns. Create a dedicated images table and use a polymorphic relationship. This way, any model in your application can have images, a user, a product, a blog post, without cluttering your main tables.

Schema::create('images', function (Blueprint $table) {
$table->id();
$table->morphs('imageable'); <em>// adds imageable_type and imageable_id</em>
$table->string('filename');
$table->string('path');
$table->string('mime_type');
$table->unsignedInteger('size'); <em>// in bytes</em>
$table->unsignedSmallInteger('width')->nullable();
$table->unsignedSmallInteger('height')->nullable();
$table->timestamps();
});

Storing image width and height can be useful for generating responsive images, validating aspect ratios, and creating thumbnails. You can easily retrieve these values during upload using PHP’s getimagesize() function.

The corresponding Eloquent model is straightforward:

class Image extends Model
{
protected $fillable = [
'filename', 'path', 'mime_type', 'size', 'width', 'height'
];

public function imageable()
{
return $this->morphTo();
}

public function url(): string
{
return asset('storage/' . $this->path . '/' . $this->filename);
}
}

What this gives you that a plain string column doesn’t: you can query images by size, filter by dimensions, eager-load them efficiently, and swap storage backends without touching your application code.

Read Full Article: https://serveravatar.com/laravel-image-upload

How to Copy and Overwrite Files in Linux Without Confirmation

Meghna Meghwani — Wed, 22 Jul 2026 07:35:27 +0000

There is a moment every Linux user runs into when trying to copy and overwrite files in Linux without confirmation. You have a script ready, everything is automated, and then a single confirmation prompt breaks the whole pipeline. You did not plan for it. The script hangs, waiting for a y that will never come. That frustration is exactly what this guide aims to address.

When you copy files in Linux, the cp command does not always behave the same way twice. On some systems, it overwrites without asking. On others, it stops and waits for input. Sometimes it refuses to touch a file at all. If you are automating anything, deployment scripts, backup routines, container image builds, these inconsistencies can quietly derail your workflow.

This is a practical guide for people who need to copy and overwrite files in Linux without confirmation. We will walk through the default behavior, every relevant flag, how shell aliases interfere, and how to write scripts that never stop mid-execution waiting for human input.

TL;DR

The cp command’s default behavior depends on your shell environment
-f forces overwrites; -n prevents them entirely
Shell aliases like cp='cp -i' can silently change behavior
Backslash prefix (\cp) bypasses aliases temporarily
The noclobber shell option provides another safety layer
Piping yes to cp automates all confirmation responses
All of this is scriptable and automation-friendly

Quick Comparison of cp Overwrite Options

Before choosing an overwrite option, it helps to understand what each cp flag does. The table below summarizes the most commonly used options so you can quickly pick the right command for your use case.

Understanding How cp Behaves by Default

Before diving into flags, it helps to understand what cp actually does when you run it on a typical Linux system.

The basic syntax is straightforward:

cp [OPTIONS] SOURCE DESTINATION

You can specify a single source file, multiple files, or an entire directory. The last argument is always treated as the destination, everything before it is the source.

Example:

cp file.txt /home/user/Documents/

Explanation:

file.txt – Source file to copy
/home/user/Documents/ – Destination directory
This copies file.txt into the Documents folder.

Why Your cp Might Ask Before Overwriting

The same cp command may overwrite files on one system but ask for confirmation on another because of a shell alias. An alias is a shell shortcut that automatically adds predefined options to a command before it runs.

Some distributions define this in their default shell configuration:

alias cp='cp -i'

The -i option enables interactive mode, prompting for confirmation before overwriting existing files.

With this alias enabled, every cp command automatically runs as cp -i. While this is helpful for manual use, it can interrupt automated scripts and deployments.

Example:

cp file.txt /home/user/Documents/

Explanation:

If there is already a same name file, it will prompt for confirmation before overwriting an existing file.txt in the backup folder.

Read Full Article: https://serveravatar.com/copy-overwrite-files-in-linux

How to Fix WordPress Stuck in Maintenance Mode

Meghna Meghwani — Tue, 21 Jul 2026 06:04:35 +0000

You just clicked “Update Now” on a plugin. Thirty seconds later, your WordPress stuck in maintenance mode and shows a white screen that says: “Briefly unavailable for scheduled maintenance. Check back in a minute.” That minute passes. Then ten. Then an hour. You refresh. Still the same message.

If you’ve been there, and plenty of WordPress users have, you already know the sinking feeling. You are locked out of your own website, and your visitors are seeing the same thing. You start wondering if you broke the internet, lost months of content, or need to restore from a backup.

Take a breath. You almost certainly didn’t break anything. Getting WordPress unstuck from maintenance mode is usually a simple fix, and you don’t need to be a server admin to do it. This guide walks you through exactly what’s happening, why it happened, and how to get your site back right now. I will also walk you through the best practices to prevent this issue from returning.

By the time you finish reading, you’ll know how to diagnose the issue, fix it yourself, and harden your setup so interruptions don’t leave you stranded again.

TL;DR

What Is WordPress Maintenance Mode, Exactly?

When WordPress runs an update, whether it’s a plugin, a theme, or the core itself, it needs a moment where nothing else touches the site while files are being swapped out. If a visitor tried to load a page mid-update, they could end up with a half-written file or corrupted database entry.

So WordPress puts the site into a brief holding state. It drops a small file called .maintenance in your root directory, and every visitor, including you, sees that “Briefly unavailable” message instead of your actual content. If you’re new to WP-CLI, the official WP-CLI documentation explains its available commands and how to use them for managing WordPress from the command line.

Under normal circumstances, this is invisible. The update finishes, WordPress deletes the .maintenance file, and everything goes back to normal within seconds.

The problem starts when something interrupts the update process before WordPress can clean up. Maybe your browser tab closed mid-upload. Maybe your internet dropped. Maybe your server ran out of memory and killed the process. When that happens, the .maintenance file stays right where it is, and your site stays locked.

I’ve seen this happen on everything from small personal blogs to agency-managed client sites. The good news is that the fix is almost always the same: find that file and remove it.

How to Tell If Your WordPress Site Is Actually Stuck

Not every slow update means your site is stuck. Sometimes WordPress really is just taking a minute to process a large plugin update. Here’s how to know the difference.

The message is the first clue. If your site displays “Briefly unavailable for scheduled maintenance. When the maintenance message stays visible for several minutes instead of disappearing, it’s usually a sign that WordPress is stuck in maintenance mode and requires manual intervention.
You can’t reach the admin dashboard. If you cannot access your WordPress admin dashboard and visiting /wp-admin redirects you back to the maintenance screen, your site is likely stuck in maintenance mode rather than simply taking longer to update.
The message persists after refreshing. Give it a few refreshes over the course of a minute or two. If it never resolves, something has interrupted the process.
You can confirm it by checking your files. You can verify the issue by checking your WordPress root directory for a .maintenance file using your hosting file manager, FTP, or SSH. If the file exists after several minutes of an update, it is likely causing the maintenance mode lock.

A useful side note: if you see the maintenance message but never initiated an update yourself, that’s actually a red flag. Someone may have triggered an update on your site without you knowing, or a plugin auto-updated itself. Either way, the fix is the same.

What Actually Causes WordPress to Get Stuck?

Understanding why this happens helps you fix it faster and avoid it in the future. Here are the most common culprits I’ve encountered in practice.

Interrupted updates are the most common reason WordPress gets stuck in maintenance mode. If an update is stopped due to a closed browser, lost connection, or system sleep, the .maintenance file may remain and keep the site locked.
Server resource limits can also cause maintenance mode issues. On shared hosting, low PHP memory limits or execution timeouts may interrupt plugin updates, especially when updating multiple plugins or handling large update files.
Plugin and theme conflicts can also interrupt updates. Incompatible plugins, outdated themes, or resource conflicts may cause the update process to fail and leave WordPress stuck in maintenance mode.
File permission problems can also prevent WordPress from exiting maintenance mode. If WordPress lacks proper write access to manage the .maintenance file, it may remain even after a successful update.
Running multiple updates at the same time can create conflicts, especially on multi-user sites. These overlapping processes may leave the .maintenance file behind and keep WordPress stuck in maintenance mode.
Manual maintenance mode activation can also be the cause. If a site owner or developer enables maintenance mode through wp-config.php or a plugin and forgets to disable it, the .maintenance file may remain and keep the site inaccessible.

How to Fix WordPress Stuck in Maintenance Mode

Here’s the step-by-step process I use every time. These steps work regardless of which hosting platform you’re on, though the exact interface will differ slightly.

Read Full Article: https://serveravatar.com/fix-wordpress-stuck-in-maintenance-mode

Hostname vs Domain Name: Key Differences Explained

Meghna Meghwani — Mon, 20 Jul 2026 06:58:20 +0000

If you have ever configured a website, managed a VPS, or set up a server, you have probably encountered the terms Hostname vs Domain Name. Although hostname and domain name are often mentioned together, they don’t mean the same thing. Understanding Hostname vs Domain Name is essential for managing websites, configuring servers, and troubleshooting DNS-related issues effectively.

This confusion is common because both are used to identify systems on a network, and in many cases they appear together in web addresses. It’s easy to assume they are interchangeable, but understanding the difference becomes important when you’re configuring DNS records, setting up email, installing SSL certificates, or deploying applications.

For example, if you are hosting a website on your own server, you’ll typically assign a hostname to the machine while pointing a registered domain name to its IP address. Knowing which one serves which purpose helps avoid configuration mistakes and makes troubleshooting much easier.

In this guide, you will learn what hostnames and domain names are, how they differ, how they work together, where each is used, and which one matters in different real-world scenarios.

TL;DR

A hostname identifies a specific device or service on a network.
A domain name identifies an internet namespace that users can access.
A hostname can exist without a public domain.
A domain can contain multiple hostnames.
Websites commonly use both together, such as “blog.example.com”.
Understanding the difference helps with DNS management, server administration, email configuration, and website hosting.

Hostname vs Domain Name: Quick Comparison

If you’re short on time, here’s the simplest way to understand the difference between a hostname and a domain name.

While hostnames and domain names often appear together, they solve different problems. A hostname identifies a specific system or service, whereas a domain name provides a memorable internet address that groups related services under one identity.

What Is a Hostname?

A hostname is the name assigned to a specific device, server, virtual machine, or network resource. Instead of identifying a machine by its numerical IP address, people can use a hostname that’s much easier to recognize and remember.

Think of a hostname as the label attached to an individual computer. For instance, imagine a company with several servers:

Application Server
Database Server
Backup Server
Monitoring Server

Each server needs its own identity, even if they’re all part of the same infrastructure. Instead of referring to them by IP addresses like 192.168.10.25, administrators assign meaningful names such as:

app-server
db-server
backup-node
monitor-01

These names simplify server management, documentation, monitoring, and troubleshooting. Hostnames are commonly used inside private networks and don’t always need to be publicly accessible.

Where Are Hostnames Used?

You will encounter hostnames in many environments, including:

Linux servers
Windows systems
Cloud virtual machines
Docker containers
Kubernetes nodes
NAS devices
Routers and firewalls
Internal enterprise networks

Whenever a new server is created, assigning a descriptive hostname is considered a best practice because it makes infrastructure easier to understand as it grows.

Need to rename a server? Follow our step-by-step guide on How to Change the Hostname on Linux Easily to update your system hostname safely.

Why Hostnames Matter

Although a hostname may seem like a simple label, it plays an important role in daily system administration. A clear naming convention can help administrators:

Identify servers quickly
Reduce deployment mistakes
Simplify monitoring dashboards
Improve log analysis
Organize infrastructure across multiple environments

For example, compare these two server names:

“server01” vs. “production-api-us-east”

The second hostname immediately tells you what the server does and where it’s located. Small improvements like this become increasingly valuable as your infrastructure scales from a handful of servers to dozens, or even hundreds.

How to Check Your System Hostname in Linux

If you’re using Linux, you can quickly view your system’s hostname using the command line. This is useful when managing servers, troubleshooting network issues, or verifying your system configuration.

Display the Current Hostname

hostname

This command prints the hostname currently assigned to your system.

Example output:

web-server

View Detailed Hostname Information
To display additional details, including the static hostname, operating system, kernel version, and hardware information, run:

hostnamectl

Example output:

Static hostname: web-server
Operating System: Ubuntu 24.04 LTS
Kernel: Linux 6.x
Architecture: x86-64

Display the Fully Qualified Domain Name (FQDN)

If your server is configured with DNS, you can display its Fully Qualified Domain Name (FQDN) using:

hostname -f

Example output:

web-server.example.com

Note: The hostname -f command works only when your system’s hostname is properly configured in DNS or the /etc/hosts file.

Read Full Article: https://serveravatar.com/hostname-vs-domain-name

How to Check Running Processes in Linux Using ps, top, htop & atop

Meghna Meghwani — Sun, 19 Jul 2026 07:00:00 +0000

Managing a Linux server involves more than installing applications and keeping the system updated. To check running processes activity effectively, it’s important to understand how Linux manages every service, from a web server and database to scheduled jobs and background scripts. When a website becomes slow, CPU usage suddenly spikes, or memory starts disappearing, the first place to investigate is the list of running processes.

Linux offers several built-in and advanced tools for monitoring what’s happening inside your system. Some provide a quick snapshot of active processes, while others continuously update resource usage in real time or record historical performance data for deeper analysis.

If you’re new to Linux administration, choosing between commands like ps, top, htop, and atop can be confusing because they all display process information in different ways. Knowing when to use each one can save time during troubleshooting and help you identify performance bottlenecks much faster.

In this guide, you’ll learn what each tool does and how to use it effectively with practical examples.

TL;DR

Linux processes are running instances of applications or system services.
The ps command provides a snapshot of currently running processes.
top displays live CPU, memory, and process activity directly in the terminal.
htop offers an interactive, user-friendly interface with easier navigation and process management.
atop records system activity over time, making it useful for diagnosing performance issues that occurred earlier.
Each tool serves a different purpose, and many administrators use them together for a more complete view of system performance.

Why Process Monitoring Matters in Linux

Every application running on your Linux server consumes system resources such as CPU time, memory, storage, or network bandwidth. Unexpected events like a runaway script, an overloaded web application, or a failing service can quickly affect overall system performance.

Regularly monitoring running processes helps you:

Identify applications consuming excessive CPU or memory.
Detect unresponsive or stuck processes.
Troubleshoot slow server performance.
Verify that essential services are running correctly.
Monitor applications after deployments or configuration changes.
Discover unusual resource usage before it impacts users.

Whether you’re managing a personal VPS or multiple production servers, understanding your system’s active processes makes troubleshooting significantly easier.

Tip: Process monitoring isn’t only for fixing problems. It’s equally useful for validating that a server is operating as expected after updates, deployments, or maintenance.

What Is a Linux Process?

A process is simply a program that is currently running on your Linux system. Every time you execute a command, start a service, or launch an application, Linux creates one or more processes to perform the required tasks.

For example:

Starting the Apache or Nginx web server creates server processes.
Connecting to a server over SSH starts a user session process.
Running a backup script creates a temporary process until the job finishes.
Database servers like MySQL or PostgreSQL continuously run multiple background processes to handle queries and maintenance tasks.

Each process is assigned a unique Process ID (PID), which allows the operating system to manage it independently.

Understanding these basics makes it much easier to interpret the output of process monitoring tools later in this guide. All utilities display process information, they solve different problems. Choosing the right one depends on whether you need a quick snapshot, continuous monitoring, easier navigation, or historical performance records.

When Should You Use Each Tool?

There’s no single “best” command for every situation. Instead, each utility fits a specific workflow.

Choosing the appropriate tool not only speeds up troubleshooting but also gives you more relevant information without unnecessary complexity.

Read Full Article: https://serveravatar.com/check-running-processes-linux

Paperclip AI Guide: Best Use Cases for Automating Business Operations

Meghna Meghwani — Sat, 18 Jul 2026 07:14:33 +0000

There is a moment every founder, CTO, or operations lead hits. You have stripped everything down to the essentials. You have automated what you can with scripts, webhooks, and no-code tools. And still, there is a feeling that you are manually stitching together a set of tools that should, by now, work like a team. Paperclip AI is designed to solve exactly this challenge by helping AI agents work together in structured, goal-driven business workflows instead of isolated automations.

That feeling is not wrong. Most automation today solves individual tasks. It does not solve coordination. Sending a Slack message when a form is filled out is useful, but it is not the same as having someone who knows why that form matters, who to hand it off to, and what to do if the next step fails.

Paperclip is built around a different idea. Instead of automating a single process, it lets you automate an entire operation, with structure, accountability, and costs that scale predictably.

This guide is not a feature list. It is a practical look at what that actually means for your business, and which use cases tend to deliver real value first.

TL;DR

The Mental Model That Changes Everything

Most people approach AI agents like smart scripts. Enter your prompt, receive a response, and continue with the next task.

Paperclip works better when you stop thinking that way and start thinking about agents like employees. Not metaphorically, structurally. Each agent has a role, a budget, a reporting line, and access to the full context of why it is doing something, not just what it was asked to do.

That distinction sounds small. It is not. A marketing agent that understands a blog post is part of a broader objective, such as reaching 10,000 quarterly signups, can make more informed decisions than one who only receives a simple instruction like, “Write a 500-word article about Paperclip.” Context drives alignment. And alignment is what separates AI agents that produce noise from those that produce progress.

This is the mental model that makes Paperclip different from Zapier, Make, or any workflow tool you have tried before. Those tools automate a process. Paperclip automates a department.

What Paperclip Actually Is

Paperclip is a Node.js application with a React dashboard. You install it on a server, define your organizational structure, assign AI agents to roles, and let them work.

Under the hood, it gives you:

Org charts: define who reports to whom
Ticketing: every task is a structured ticket with owner, status, and thread
Per-agent budgets: set spending limits so one agent cannot burn through your entire API quota
Immutable audit log: every decision, tool call, and API request is recorded
Multi-company isolation: run completely separate operations from one deployment

It is open source, self-hosted, and does not send your data anywhere. If you care about where your business data lives, that matters.

Deployment Note: You’ll need to install PostgreSQL, configure the required environment variables, and deploy the application manually. To simplify the process, follow our step-by-step guide on deploying Paperclip on a VPS with ServerAvatar.

Paperclip vs Traditional AI Automation

This comparison highlights how Paperclip differs from traditional AI automation platforms by offering structured agent management, governance, auditability, and scalable business operations instead of isolated task automation.

Read Full Article: https://serveravatar.com/paperclip-ai-use-cases

How to Deploy Paperclip on a VPS with ServerAvatar

Meghna Meghwani — Thu, 16 Jul 2026 06:47:45 +0000

If you’re looking to deploy Paperclip for your team, a VPS gives you full control over your AI infrastructure. Paperclip is an open-source platform that lets you create AI agents, define goals, and connect LLM providers like Anthropic Claude and OpenAI, all from a clean dashboard. The catch is that the hosted version stores your data in Paperclip’s cloud. For companies with strict data privacy requirements, or teams that simply want complete ownership of their infrastructure, self-hosting is the better choice. In this guide, you’ll learn how to deploy Paperclip on a VPS quickly and securely using ServerAvatar.

This guide walks you through deploying Paperclip on a VPS running Ubuntu, behind a custom domain, with HTTPS, a proper PostgreSQL database, and authentication required for every user.

ServerAvatar handles the heavy lifting on server provisioning, application deployment, and SSL certificate management, so you can focus on the setup itself rather than wrestling with DNS records and firewall rules.

TL;DR

Paperclip is an open-source AI agent management platform with a web UI
Self-hosting gives you full data ownership and keeps agent data on your own infrastructure
ServerAvatar simplifies VPS provisioning, application deployment, and SSL management
PostgreSQL 17 is required, Paperclip’s Drizzle ORM doesn’t support MySQL or MariaDB
Paperclip listens on 127.0.0.1:3100 only, Apache handles all public traffic through a reverse proxy
A clean install on a fresh Ubuntu VPS takes roughly 15–20 minutes

What is Paperclip?

Paperclip is an open-source platform that gives teams a web-based control panel for AI agents. You can define agents, assign them goals, manage workloads, and connect your own LLM API keys, without having to build your own tooling from scratch.

Explore the hosted version at paperclip.ing, and access the official documentation and GitHub repository to learn more.

Going the self-hosted route changes the picture significantly:

The self-hosted approach makes the most sense when data residency, internal privacy policies, or avoiding another SaaS dependency are driving your decisions. If any of those resonate, keep reading.

Who this guide is for: Teams that need full control over agent management data, companies with compliance requirements, and developers comfortable on the command line. Budget about 15–20 minutes for a clean install on a fresh VPS.

Architecture Overview

Before diving into the steps, it helps to understand how everything connects.


 ┌──────────────────────────────────────────────┐
 │                   Your VPS                   │
 │                                              │
 │                                              │
Internet ─────────────── Apache :443 (SSL) ─────┼──────► Paperclip :3100
(https://paperclip.example.com)   │             │               │
                                  │ Apache :80──┘               │
                                  │                             │
                                  │   PostgreSQL :5432          │
 └──────────────────────────────────────────────┘

Here’s what each piece does:

Apache (443) – Terminates SSL, handles Let’s Encrypt certificates, receives all public traffic
Apache (80) – Catches plain HTTP requests and redirects them to HTTPS
Paperclip (3100) – The agent management UI that is tied exclusively to localhost, and never directly exposed to the internet
PostgreSQL (5432) – Stores all agent data, configurations, and user information, also localhost-only

Traffic always flows: Client >> Apache (SSL) >> Paperclip (localhost) >> PostgreSQL (localhost). Nothing is directly reachable from the internet except Apache on ports 80 and 443.

Why this design matters

Paperclip is intentionally designed to sit behind a reverse proxy. It binds to 127.0.0.1:3100, which means it cannot be reached directly from the internet under any misconfiguration. Apache handles all SSL complexity. PostgreSQL is on localhost too, so you don’t need to open firewall rules for the database. “systemd” takes care of restarts if the process crashes or the server reboots.

This layered approach means you get a production-ready setup where each component only communicates with the ones it actually needs to.

Step 1: Create Your Server with ServerAvatar

Log into your ServerAvatar account and create a new server. If you already have a server, ServerAvatar makes the process straightforward, you can connect your server from any cloud provider with ServerAvatar using the Direct Method installation guide.

You can also connect your cloud provider account from DigitalOcean, Vultr, Linode, Hetzner, and Amazon Lightsail to directly deploy a server using ServerAvatar.

During the server creation workflow, you’ll see an option to Install Node.js, enable this toggle. Paperclip runs on Node.js, and having ServerAvatar install it during provisioning saves you a manual step afterward.

Step 2: Create the Application in ServerAvatar

After your server is live, create a new application in ServerAvatar.

Open the server panel by clicking on the server dashboard icon.
Navigate to the Application section from the left sidebar.
Click on the Create an Application button.

Enter your application name.
Select your domain from Primary and Test. ServerAvatar lets you deploy applications on a temporary test domain first, useful for verifying your setup before pointing production traffic at it.
Enter your domain name.
Choose Custom PHP Application as the deployment method.

Click on Show Advance Options. Enter New User and give Username and Password.
Select your PHP Version as 8.2
Click on Create Application.

ServerAvatar will create the application structure and set a document root. You’ll deploy Paperclip into this environment. Refer to the custom PHP deployment guide for further details.

Read Full Article: https://serveravatar.com/deploy-paperclip-on-vps

How to Reduce HTTP Requests in WordPress to Improve Site Speed

Meghna Meghwani — Wed, 15 Jul 2026 06:24:04 +0000

Every time someone visits your WordPress site, their browser has to do many things. To reduce HTTP requests, it first has a list of files it needs before it can show a single pixel. CSS files. JavaScript files. Images. Fonts. Tracking pixels. Font icons. Video embeds.

Each item on that list is one HTTP request. And here’s the thing most people don’t realize until they actually look: that list is usually way longer than it needs to be.

I remember opening GTmetrix for a client’s WordPress site for the first time a couple of months ago and seeing 94 requests for a simple blog page. The site was loading four separate JavaScript files from a plugin the client had forgotten they even installed. Just disabling that one plugin brought it down to 71 requests and dropped the load time by nearly two seconds. That’s the kind of gap we’re talking about here.

In this guide, I’m going to walk you through how HTTP requests actually work in WordPress, how to measure them properly, and, more importantly, which optimizations actually move the needle.

TL;DR

Every file your browser fetches is a separate HTTP request, more requests mean a slower site
The biggest culprits are heavy plugins, unoptimized fonts, external tracking scripts, and oversized images
You can cut requests dramatically by auditing what loads, hosting assets locally, deferring non-critical scripts, and using modern formats

What Actually Are HTTP Requests

Think of your browser like a customer in a restaurant where every ingredient needed for a dish comes from a different supplier. Each supplier call represents an HTTP request. The browser makes these requests over a network (not a phone line, but the idea is similar), and every single request introduces a small delay or latency before the page can fully load.

How This Works in WordPress" width="652" height="407">

How This Works in WordPress

Every WordPress page is built using multiple assets that the browser must load before displaying the page.
These assets include CSS stylesheets, JavaScript files, fonts, images, and other supporting resources.
The browser sends a separate request to the server for each asset.
It waits for the server to respond before downloading the requested file.
Once the file is received, the browser continues requesting the remaining assets.
This sequence is repeated until every required resource has been downloaded and processed.
The more assets a page contains, the more requests the browser needs to make before the page is fully rendered.

Every resource that your browser downloads requires its own HTTP request. Understanding which assets generate requests helps you identify where optimization efforts will have the biggest impact.

The table below highlights the most common asset types found on WordPress websites and the best ways to optimize them.

Why This Becomes a Problem

Every file request takes time, even on a fast internet connection.
Requests to a local server are typically faster, while external resources introduce additional delay.
Third-party services, such as analytics, advertising scripts, or embedded widgets, often take the longest to respond.
A typical WordPress page can generate 80 to 100 or more individual requests.
As these requests add up, the browser spends more time waiting for resources to load.
The extra waiting time delays page rendering and interactivity.
This results in slower page load speeds, a poorer user experience, and can negatively affect website performance.

Impact on Performance & SEO

Slow page loading affects more than just the visitor experience.
Search engines consider page speed as one of the signals when evaluating website quality and rankings.
Excessive network requests can slow down the delivery of important page content.
Google Core Web Vitals are directly impacts important performance metrics, including Largest Contentful Paint (LCP).
Delayed loading of scripts and resources can also affect Interaction to Next Paint (INP) by making the page less responsive.
The more requests a page makes, the longer it takes to load and become interactive.
Reducing unnecessary requests can improve performance scores, user satisfaction, and overall SEO.

I’ll skip the surface-level advice and focus on the changes that genuinely speed up a live site. If you want a broader view, I’ve written a complete guide to speeding up WordPress with optimization methods that covers everything from caching to image optimization.

Why Reducing Requests Matters More Than You Think

I’ve seen developers spend days optimizing database queries when the real bottleneck was twenty JavaScript files loading synchronously on every single page. The database was fine. The theme was fine. The plugins were the problem.

When you cut down HTTP requests, three things happen:

First, the browser has less work to do. It downloads fewer files, parses less code, and renders the page faster. For your visitors, this means a noticeably snappier experience, especially on mobile, where network conditions are less predictable.

Second, your server handles less work. Each request consumes CPU and memory on the server side. Fewer requests means your server can serve more visitors simultaneously without breaking a sweat. For growing sites, this is the difference between a server that scales and one that falls over during a traffic spike. If your server response time is already slow, start with my TTFB optimization guide first.

Third, your Core Web Vitals improve. Google measures how quickly your page becomes interactive. Fewer requests means faster LCP, lower INP, and better CLS scores. That directly translates to better rankings.

The good news: you don’t need to overhaul your entire site. A handful of targeted fixes usually handles the bulk of the problem.

Read Full Article: https://serveravatar.com/improve-wordpress-site-speed

How to Add Expires Headers in WordPress

Meghna Meghwani — Tue, 14 Jul 2026 06:36:05 +0000

If you want to add expires headers in WordPress, it’s important to understand how browsers handle your website’s static files. Every time a visitor lands on your WordPress site, their browser downloads images, stylesheets, fonts, scripts, and other assets. If your server doesn’t instruct the browser to store these files locally for a certain period, it has to download them all over again on the next visit. This increases page load times, consumes more bandwidth, and negatively impacts your site’s performance.

The “Add Expires Headers” warning shows up in tools like Google PageSpeed Insights and GTmetrix precisely because it has a measurable impact on page speed. Beyond the audit score, slow-loading assets eat bandwidth, hurt your SEO, and create a poor experience, especially for returning visitors.

This guide walks you through exactly how to fix it. You’ll learn what Expires Headers actually do, how they differ from Cache-Control, which file types should be cached for how long, and most importantly, how to set everything up on your server without breaking your site.

TL;DR

Expires Headers tell browsers how long to keep cached files before asking the server again
They directly improve load speed for returning visitors and reduce server bandwidth
CSS, JS, images, and fonts should be cached for extended periods; HTML should not
NGINX uses expires directives inside location blocks; Apache uses mod_expires in .htaccess
Clear your site cache after making changes, and always test before going live

What Are Expires Headers, Exactly?

When a browser requests a file from your server, the server responds with the file along with HTTP headers. These headers are invisible to visitors but carry instructions that browsers follow.

An Expires Header tells the browser: “Keep this file in your local cache until this specific date and time. Don’t bother asking me for it again until then.”

Without it, the browser has no persistent instruction. It may still cache files temporarily based on its internal heuristics, but it will frequently revalidate with your server, adding latency to every page load.

What this looks like in practice: a first-time visitor downloads your entire page design. A returning visitor three days later should theoretically load everything from their local cache. But without Expires Headers, the browser checks with your server anyway, waiting for confirmation that the files haven’t changed. For a text-heavy page with multiple assets, those round-trips add up fast.

Expires vs. Cache-Control: Why You Need to Know Both

These two get confused constantly, and for good reason, they do essentially the same job. But they go about it differently.

Here’s the practical detail that trips people up: if both headers are present, Cache-Control wins. Browsers prioritize the newer standard and ignore the older Expires date when both exist. Mozilla’s MDN documentation on HTTP caching is a solid reference if you want to go deeper on how these headers interact.

Which One Should You Use?

Most servers today default to Cache-Control because it’s cleaner and more precise. But if you’re manually configuring headers, there’s no harm in setting both, you just need to make sure they don’t contradict each other, or the Expires header becomes meaningless noise.

How Long Should Each File Type Be Cached?

Not every asset on your site deserves the same caching treatment. Getting this right is where a lot of people go wrong, either over-caching things that change often, or under-caching things that never change.

Here’s the logic:

Files that rarely change, like images, stylesheets, JavaScript, and fonts, are ideal candidates for long-term caching. You set them once, and browsers hold onto them for months. The performance gain is substantial because these are typically the heaviest files on any page.
Files that change frequently, like your HTML documents, should get short or zero caching. Your HTML is where new content lives. If a visitor’s browser caches your homepage for a year, they’ll never see your latest blog post. It kills content freshness and makes your site feel broken.
Third-party files, like Google Analytics scripts or Facebook Pixels, are outside your control. You can’t set headers on files you don’t host, so don’t worry about those in your configuration.

Read Full Article: https://serveravatar.com/add-expires-headers-wordpress

How to Remove WordPress Default Image Sizes: Step-by-Step Guide

Meghna Meghwani — Mon, 13 Jul 2026 06:16:43 +0000

If you’ve uploaded images to WordPress, you’ve probably noticed your wp-content/uploads folder filling up with multiple copies of the same image. That’s because WordPress Default Image Sizes automatically generate several resized versions of every uploaded image, even if your website never uses them. Over time, these extra files can consume valuable server storage, clutter your media library, and make backups larger than necessary.

Over time, these extra files waste storage, increase upload processing, and add unnecessary server load. While WordPress lets you change image dimensions, it doesn’t provide a built-in option to disable image size generation completely.

In this guide, you’ll learn how to stop WordPress from creating unused image sizes using a plugin or code, and how to clean up the extra images already stored in your media library.

TL;DR

WordPress creates thumbnail, medium, and large versions of every image you upload by default
These extra files consume server storage and increase upload processing time
You can stop this behavior using a plugin or by adding a filter to your theme’s functions.php file
Existing images need a separate cleanup step to remove previously generated sizes
Choose the method that matches your comfort level with code

What WordPress Does Behind Every Image Upload

Uploading an image to the WordPress Media Library does more than simply save the original file. During every upload, WordPress automatically creates multiple resized versions of that image for use across different areas of your website.

By default, WordPress generates:

Thumbnail: 150 × 150 px (cropped square), commonly used for galleries and widgets.
Medium: Maximum 300 px on the longest side.
Large: Maximum 1024 px on the longest side.
Full Size: The original uploaded image (unchanged).

Custom Image Sizes

The default sizes are only part of the story. Many themes and plugins register their own image dimensions, including:

Page builders
Gallery plugins
Slider plugins
WooCommerce
Custom WordPress themes

As a result, uploading one image can generate 5–10+ files depending on your site’s configuration.

Why It Becomes a Problem

If your website stores hundreds or thousands of images, these additional copies consume a significant amount of server resources.

Common drawbacks include:

Increased disk usage
Slower image uploads
Longer backup times
Higher storage costs
Extra CPU usage during image processing
Larger media libraries to maintain

Example

500 original images × 2 MB each = 1 GB
If WordPress creates five additional sizes per image, total storage can easily exceed 5 GB, even when many of those files are never used.

If your theme never displays certain image sizes, generating them simply wastes storage and processing power.

Two Ways to Control WordPress Image Size Generation

You have two solid paths to stop WordPress from generating image sizes you don’t need.

The plugin route is the most approachable, it gives you a settings interface and doesn’t require touching any code.
The code route is more precise and doesn’t add another plugin to your site, but it does mean working with your theme’s functions.php file.

Neither approach is wrong. Pick based on what you’re comfortable with.

Read Full Article: https://serveravatar.com/remove-wordpress-default-image-sizes