DEV Community: Nitin Mehta

I Built a Self-Hosted WhatsApp Gateway Using Node.js, Docker and PostgreSQL

Nitin Mehta — Sat, 31 Oct 2026 04:39:03 +0000

Building Puffx WhatsApp Gateway: A Self-Hosted WhatsApp Messaging API with Node.js, Docker and PostgreSQL

Author: Nitin Mehta

Project: Puffx WhatsApp Gateway

GitHub Repository: https://github.com/puffxhost/puffx-whatsapp-gateway

Website: https://puffxhost.com

Introduction

What if developers could run their own WhatsApp messaging gateway instead of depending entirely on a third-party hosted messaging service?

That question inspired me to build Puffx WhatsApp Gateway, an open-source, self-hosted messaging gateway designed to connect a WhatsApp account with applications through a REST API.

The project brings together a web dashboard, WhatsApp account pairing, API key authentication, PostgreSQL, and Docker-based deployment.

The main idea is simple:

Run the gateway on your own computer or VPS.
Connect a WhatsApp account using QR pairing or a phone pairing code.
Manage the connected session through a web dashboard.
Generate an API key.
Send text messages from your own backend applications using HTTP requests.

I built this project under Puffx Host to explore backend development, API architecture, self-hosted infrastructure, and messaging integrations.

The project is currently in its initial beta stage.

Explore the source code:

https://github.com/puffxhost/puffx-whatsapp-gateway

1. What Is Puffx WhatsApp Gateway?

Puffx WhatsApp Gateway is a self-hosted application that exposes a REST API for sending text messages through a paired WhatsApp Web session.

Instead of using a gateway hosted by someone else, developers can deploy the application on infrastructure they control.

The application provides a web dashboard for managing sessions and API credentials.

Main Features

1. QR Code Pairing

Connect a WhatsApp account by scanning a QR code using WhatsApp's Linked Devices feature.

2. Phone Pairing Code

The project also supports an alternative phone pairing code flow.

3. Web Dashboard

Manage your account, create WhatsApp sessions, check connection status, and generate API keys.

4. REST API

Send text messages programmatically through an HTTP endpoint.

5. API Key Authentication

The API uses Bearer token authentication to authorize message requests.

6. PostgreSQL Database

PostgreSQL stores application data.

7. Docker Deployment

Docker Compose provides a convenient way to run the gateway and its database together.

8. Persistent Session Storage

Docker volumes preserve database data and WhatsApp authentication state across normal container restarts.

2. Technology Stack

I used the following technologies and tools to build the project.

Technology	Purpose
Node.js	Backend runtime
TypeScript	Application development
PostgreSQL	Database
Docker	Containerization
Docker Compose	Service orchestration
REST API	Application integration
Baileys	WhatsApp Web connectivity

Why Docker?

A self-hosted application should be relatively straightforward to deploy and maintain.

Docker makes it easier to package the gateway and database into a consistent environment.

Instead of manually configuring every dependency, developers can start the application using Docker Compose.

Why PostgreSQL?

The project needs persistent application data. PostgreSQL provides a relational database for managing that information.

3. Understanding the Architecture

At a high level, the application has four important parts:

Dashboard: The interface used to manage accounts, sessions, and API keys.
Backend API: Handles authentication, session management, and message requests.
PostgreSQL: Stores persistent application data.
WhatsApp Web integration: Handles the paired WhatsApp session and communication.

The basic message flow looks like this:

Your Application
       |
       | HTTP Request
       v
Puffx REST API
       |
       | Bearer Token Authentication
       v
Session Validation
       |
       v
WhatsApp Integration
       |
       v
WhatsApp Network

This architecture allows another backend application to communicate with the gateway without directly managing the WhatsApp session itself.

4. Installing the Project with Docker

One of the main goals was to make local setup accessible to developers.

Requirements

Before starting, install:

Docker Desktop or Docker Engine.
Docker Compose.
Git.
A WhatsApp account that can use Linked Devices.

For Windows users, Docker Desktop should be installed and running.

Step 1: Clone the Repository

Open Windows CMD, PowerShell, or a terminal on Linux/macOS.

git clone https://github.com/puffxhost/puffx-whatsapp-gateway.git

cd puffx-whatsapp-gateway

Step 2: Configure Environment Variables

Copy the example environment configuration.

On Windows CMD:

copy .env.example .env

On Linux/macOS:

cp .env.example .env

Open the .env file and configure the required secrets.

POSTGRES_PASSWORD=your_strong_database_password
SESSION_SECRET=your_random_session_secret
API_KEY_PEPPER=your_random_api_key_pepper

Use unique, randomly generated values.

The session secret and API key pepper should be different from each other.

Important: Never commit your real .env file to a public repository.

Step 3: Start Docker Compose

Run:

docker compose up -d --build

Docker Compose will build and start the gateway and database services.

Step 4: Open the Dashboard

After the services start, open:

http://127.0.0.1:3000

You can also check the readiness endpoint:

http://127.0.0.1:3000/api/v1/ready

The endpoint should report that the application is ready.

Step 5: Check Container Status

Run:

docker compose ps

To view gateway logs:

docker compose logs -f gateway

To restart the gateway:

docker compose restart gateway

To stop the services while preserving data:

docker compose down

Be careful with docker compose down -v. It removes the associated named volumes and can permanently delete the database and WhatsApp login data.

5. Connecting a WhatsApp Account

After opening the dashboard, follow these steps:

Create an account in the dashboard.
Select Add session.
Give your WhatsApp session a name.
Choose QR pairing or phone pairing code.
For QR pairing, open WhatsApp on your phone.
Navigate to Settings → Linked Devices → Link a Device.
Scan the displayed QR code.
Wait until the session status becomes connected.

Once connected, the session is available for API integration.

Security note: Never share QR codes, pairing codes, WhatsApp authentication files, or session backups with anyone.

6. Generating an API Key

After connecting your WhatsApp session:

Open the connected session in the dashboard.
Select Create API key.
Copy the generated key immediately.
Store it securely on your backend server.

The key is displayed only once.

If you lose it, revoke it and generate a new key.

The API key is associated with the session selected when it was created.

The session UUID is also required when making a message request. Use the dashboard's Copy ID option to obtain it.

7. Sending Your First WhatsApp Message Through the REST API

This is one of the most important parts of the project.

Once the gateway is running and a WhatsApp session is connected, another application can send a text message using an authenticated HTTP request.

API Endpoint

POST /api/v1/messages/send

Authentication

Authorization: Bearer YOUR_API_KEY

Request Body

{
  "sessionId": "YOUR_SESSION_UUID",
  "to": "919876543210",
  "type": "text",
  "message": "Hello from Puffx WhatsApp Gateway!"
}

Replace the example phone number with the recipient's number, including the country code and digits only.

Complete cURL Example

curl -X POST "http://127.0.0.1:3000/api/v1/messages/send" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "sessionId": "YOUR_SESSION_UUID",
    "to": "919876543210",
    "type": "text",
    "message": "Hello from Puffx WhatsApp Gateway!"
  }'

Replace the API key and session UUID with your actual values.

The API returns HTTP 202 when the provider accepts the message request.

An important distinction: HTTP 202 does not guarantee successful delivery or confirm that the recipient has read the message.

Delivery and read receipts are not currently implemented in this beta.

8. Integrating with Other Programming Languages

The gateway is designed to be accessed through HTTP, so a developer can integrate it with a backend written in different programming languages.

Examples and integration guidance are included in the repository's API documentation.

Potential client applications include:

Node.js applications.
PHP applications.
Python applications.
Internal business tools.
Backend automation systems.

For example, a PHP application could make an HTTP POST request to the gateway with its API key stored in a server-side environment variable.

Never expose an API key in frontend JavaScript, a public GitHub repository, or a mobile application's publicly accessible configuration.

For detailed examples, refer to:

https://github.com/puffxhost/puffx-whatsapp-gateway/blob/main/docs/api-reference.md

9. Can It Run on a VPS?

Yes. The application is designed for self-hosted deployment on a Linux VPS or cloud virtual machine.

A typical deployment needs:

Linux server.
Docker Engine.
Docker Compose.
PostgreSQL.
Persistent storage.
Domain name.
HTTPS reverse proxy.
Outbound WebSocket connectivity.

For public deployments, the gateway should run behind an HTTPS reverse proxy such as Nginx.

The repository includes deployment documentation and an example Nginx configuration.

A typical deployment workflow:

Domain
  |
  v
HTTPS Reverse Proxy
  |
  v
Puffx WhatsApp Gateway
  |
  +------ PostgreSQL
  |
  +------ Persistent WhatsApp Session Data

The Docker Compose configuration binds the gateway to localhost on port 3000. The reverse proxy forwards HTTPS requests to that local service.

Ordinary shared hosting and static website hosting are generally unsuitable because the application requires continuously running services and persistent writable storage.

For additional information:

Docker deployment: https://github.com/puffxhost/puffx-whatsapp-gateway/blob/main/docs/docker-deployment.md
VPS deployment: https://github.com/puffxhost/puffx-whatsapp-gateway/blob/main/docs/vps-deployment.md
Installation guide: https://github.com/puffxhost/puffx-whatsapp-gateway/blob/main/docs/installation.md

10. Security Considerations

Self-hosting gives developers control over their infrastructure, but it also means they are responsible for securing it.

Some important considerations:

Environment Secrets

Use strong, unique secrets for the database password, session secret, and API key pepper.

HTTPS

Never expose a public dashboard or API over unencrypted HTTP. Configure a valid TLS certificate.

API Key Protection

Keep API keys in backend environment variables or a secret manager.

Session Data

WhatsApp authentication state is stored on disk and is not encrypted by the application. Protect the Docker volume and its backups.

Database Backups

Back up PostgreSQL and the WhatsApp authentication volume. Treat both as sensitive data.

Access Restrictions

Do not expose internal database ports or unnecessary services to the public internet.

Read the full security documentation before deploying publicly:

https://github.com/puffxhost/puffx-whatsapp-gateway/blob/main/docs/security.md

11. Current Beta Status and Limitations

I want to be transparent about the current state of the project.

Puffx WhatsApp Gateway is an initial beta implementation.

Currently supported functionality:

WhatsApp QR pairing.
Phone pairing code.
Web dashboard.
Session management.
API key creation.
REST API authentication.
Text message sending.
Docker Compose deployment.

Current limitations:

Only text messages are supported.
Media messaging is not implemented.
Webhooks are not implemented.
Message queues are not implemented.
Delivery and read receipts are not implemented.
There is no separate admin console.
Real WhatsApp pairing and delivery behavior have not been verified by automated tests.

These limitations are important. The project should not be treated as a fully production-ready messaging platform.

12. Why I Started This Project

I enjoy exploring how software systems work beyond the frontend.

Working on this project has given me an opportunity to explore:

Backend architecture.
REST API design.
Database integration.
Docker-based deployment.
Authentication and secrets management.
Persistent application data.
VPS infrastructure.
WhatsApp Web connectivity.

I also wanted to build a practical tool that other developers could inspect, run, and experiment with.

This is an ongoing learning and development project under Puffx Host.

13. Open Source and Community Feedback

The project is publicly available on GitHub.

I welcome feedback from developers who work with:

Node.js.
TypeScript.
PostgreSQL.
Docker.
REST APIs.
Backend development.
Self-hosted infrastructure.

You can explore the source code, read the documentation, report issues, and contribute improvements.

GitHub Repository:

https://github.com/puffxhost/puffx-whatsapp-gateway

If you find a bug or have a technical suggestion, please open an issue in the GitHub repository.

Conclusion

Puffx WhatsApp Gateway is my attempt to build a self-hosted messaging gateway with a practical REST API and Docker-based deployment.

It is still in beta, and there is plenty of room for improvement.

Building this project has been a useful experience in backend engineering, infrastructure, and API development.

I would love to hear your feedback:

What would you improve in a self-hosted WhatsApp messaging gateway?

Would you focus on better session management, more API capabilities, monitoring, or deployment improvements?

Explore the project:

https://github.com/puffxhost/puffx-whatsapp-gateway

Built by Nitin Mehta | Puffx Host

Website: https://puffxhost.com

GitHub: https://github.com/puffxhost

Disclaimer

Puffx WhatsApp Gateway uses Baileys, an unofficial WhatsApp Web integration. It is not the official WhatsApp Business Platform and is not affiliated with, endorsed by, or sponsored by WhatsApp or Meta.

WhatsApp pairing and service availability may change. Users are responsible for complying with applicable WhatsApp terms, local laws, privacy requirements, and recipient-consent requirements. Use this project responsibly.

PHP2Shell: Two Critical PHP Security Vulnerabilities Every Developer Should Know About

Nitin Mehta — Fri, 23 Oct 2026 05:55:24 +0000

PHP2Shell Explained: Critical PHP RCE Vulnerabilities, Affected Versions, and How to Secure Your Server

Two critical PHP vulnerabilities have put web application security in the spotlight. Here is what developers, DevOps engineers, and hosting providers need to know.

On October 21, 2026, the PHP project released security updates addressing two critical vulnerabilities identified as CVE-2026-109618 and CVE-2026-109619, collectively discussed under the name PHP2Shell.

These vulnerabilities can allow unauthenticated remote code execution (RCE) on affected PHP installations. In practical terms, a vulnerable server may process a specially crafted network request in a way that allows an attacker to execute unauthorized code.

The PHP runtime is used across a large portion of the web, making these vulnerabilities important for developers, system administrators, managed hosting providers, and organizations running PHP-based applications.

Read the full security report from Puffx Host: PHP2Shell: Critical PHP Flaw — Update Now

In this article, we will examine how PHP2Shell works at a high level, which versions are affected, how to prioritize remediation, and what you should check before considering a server secure.

1. What Is PHP2Shell?

PHP is a server-side programming language that processes application logic, interacts with databases, handles requests, and generates dynamic web pages.

It is used by popular platforms and applications, including WordPress, Drupal, and many custom PHP websites.

PHP2Shell refers to two critical vulnerabilities in the PHP runtime itself. This distinction matters because a vulnerability in the language runtime can affect multiple applications running on the same server.

The reported issues are not limited to a particular WordPress plugin or application framework. They concern the underlying PHP runtime that processes web requests.

The two vulnerabilities are:

CVE-2026-109618: Remote code execution associated with memory corruption during out-of-memory handling.
CVE-2026-109619: Remote code execution associated with stale internal state and use-after-free behavior.

Both vulnerabilities were assigned a reported CVSS v4.0 severity score of 9.2, placing them in the critical category.

Official references:

2. Why Is Remote Code Execution So Dangerous?

Remote code execution is one of the most serious classes of application security vulnerability.

Normally, a web server receives a request, processes it through the application stack, and returns a response. A runtime vulnerability can disrupt that expected process.

If an attacker successfully exploits an RCE vulnerability, the attacker may be able to execute code with the privileges of the affected server process.

Depending on those permissions and the server's configuration, potential consequences include:

Access to sensitive application data.
Unauthorized changes to website files.
Exposure of database credentials stored in configuration files.
Installation of malicious scripts or backdoors.
Abuse of server resources.
Attempts to access other services or applications available to the compromised account.

These are potential consequences of successful exploitation, not proof that every vulnerable website has been compromised.

The actual impact depends on factors such as process permissions, isolation between hosting accounts, filesystem access, application architecture, and other security controls.

3. Technical Overview: How the Two Vulnerabilities Differ

Understanding the underlying concepts helps developers understand why runtime patches are important.

CVE-2026-109618: Memory Corruption During Out-of-Memory Handling

Applications have memory limits to prevent excessive resource consumption.

PHP can interrupt request processing when a request exceeds the configured memory limit. During that interruption, internal request data may not have been fully initialized.

The reported vulnerability involves cleanup logic handling invalid or partially initialized internal data as though it were valid.

This creates an opportunity for memory corruption under the relevant conditions.

The important engineering lesson is that error handling and cleanup paths are part of the security boundary. Code that runs when an application fails must be just as carefully designed and tested as code that handles normal requests.

CVE-2026-109619: Stale Internal State

A use-after-free vulnerability occurs when software continues to use a memory reference after the memory it points to has been released.

The memory may subsequently be reused for something else. If the application continues to treat the old reference as valid, unexpected behavior can follow.

In the reported PHP2Shell issue, internal state can survive after the memory associated with it has been freed. A subsequent operation may encounter that stale state before it has been properly reinitialized.

The risk depends on the runtime configuration and the execution path involved.

These are runtime-level problems. Fixing an unrelated application bug or updating a WordPress plugin does not, by itself, repair a vulnerable PHP runtime.

4. Which PHP Versions Are Affected?

The PHP project published security releases for four branches on October 21, 2026.

PHP branch	Security-fixed release
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Install the appropriate patched release or a verified security-fixed package supplied by your operating system or hosting vendor.

What about PHP 8.1, 8.0, and 7.4?

Older branches require special attention because they are no longer covered by the same official release process as currently supported branches.

The PHP project has published minimal source backports for certain older branches, and some operating-system vendors provide their own security fixes. Availability depends on the specific branch and package source.

If your server runs an older version:

Check whether your distribution or hosting vendor supplies a security backport.
Confirm that the installed package includes the relevant fix.
Plan a migration to a supported PHP branch.
If you cannot mitigate the exposure promptly, restrict public access until remediation is possible.

Do not judge security solely by the displayed version number. Some vendor packages backport security patches without changing the upstream version string to the latest release number.

Reference: PHP Supported Versions

5. How to Check Your Website's PHP Version

A common mistake is checking the PHP version available in the terminal and assuming the website uses the same runtime.

That is not always true.

A server can have multiple PHP versions installed, with different versions assigned to individual domains, command-line jobs, containers, or PHP-FPM pools.

Method A: Using SSH

Run:

php -v

This shows the PHP version used by the command-line executable resolved by your shell.

You can also check which executable is being used:

which php

On Windows, the equivalent command is:

where.exe php

These commands help identify the CLI runtime, but they do not independently establish which PHP runtime is serving your website.

Method B: Using cPanel

For websites hosted through cPanel:

Sign in to cPanel.
Open MultiPHP Manager or Select PHP Version, depending on your configuration.
Locate the domain you want to inspect.
Check its assigned PHP version.
Ask your hosting provider whether the actual serving runtime has received the relevant security update.

If you manage your own VPS or dedicated server, also inspect the package source, PHP-FPM pools, Apache configuration, and any containers that run PHP.

Avoid leaving a public phpinfo() page accessible on production websites. Such pages can disclose sensitive configuration details.

6. How to Patch PHP2Shell Properly

A security update is not complete merely because a package was downloaded or a version setting was changed.

You need to confirm that the running service actually uses the fixed runtime.

Step 1: Inventory your PHP installations

Identify all systems that may contain PHP, including:

Public-facing websites and APIs.
WordPress and Drupal installations.
cPanel and Plesk hosting accounts.
VPS and dedicated servers.
PHP-FPM and Apache mod_php deployments.
Containers and deployment images.
Third-party products and appliances that bundle PHP.
Development, staging, and internal applications.

Do not rely only on your main website inventory. A forgotten subdomain or an old application can still expose a vulnerable runtime.

Step 2: Prioritize internet-facing systems

Start with publicly accessible systems, particularly those running vulnerable PHP versions.

The PHP team identified Apache mod_php as a particularly high-risk configuration because a demonstrated attack path can be reached before application code executes.

Other request-serving PHP configurations—including PHP-FPM, php-cgi, FrankenPHP, and LiteSpeed—also require assessment.

Step 3: Install the correct security update

Use the package manager or trusted software distribution channel for your environment.

For example, on a Debian- or Ubuntu-based system, you can inspect installed PHP packages with:

dpkg -l | grep -E 'php[0-9.-]*'

On a compatible RPM-based system, you can inspect installed packages with:

rpm -qa | grep -i '^php'

These are inventory commands, not patching commands. The correct update procedure depends on your operating system, configured repositories, PHP installation method, and application requirements.

Do not blindly replace system PHP packages with unrelated packages from an untrusted repository.

Step 4: Restart the relevant services

After installing an update, restart or reload the relevant PHP and web server services as required by your environment.

For example, a PHP-FPM deployment may require restarting the appropriate PHP-FPM service, while an Apache deployment may require restarting Apache or its relevant PHP handler.

Service names differ between operating systems and PHP versions. Confirm the correct service before running administrative commands.

Step 5: Verify the running runtime

Check the package status and the PHP version serving the application. Verify that the appropriate fix is present and that old worker processes have been replaced.

Step 6: Test the application

Check important application functions, including:

Login and session handling.
File uploads.
Database connectivity.
API endpoints.
Background jobs and cron tasks.
Payment and checkout workflows.
Error logs and application performance.

A successful update should leave the application functional while ensuring the relevant security fix is active.

7. Are WordPress Websites Affected?

WordPress is written primarily in PHP, so the PHP runtime used by a WordPress website must be assessed.

Updating WordPress core, themes, or plugins is important, but those updates are not substitutes for patching the underlying PHP installation.

WordPress administrators should:

Confirm the PHP version assigned to their website.
Contact their hosting provider if they cannot verify the runtime.
Apply a compatible security-fixed PHP package.
Update WordPress core, plugins, and themes.
Back up the site and database.
Review logs for suspicious activity.
Test the website after the change.

The same principle applies to Drupal, custom PHP applications, and other platforms that depend on PHP.

8. What If You Cannot Update Immediately?

The preferred solution is to apply the appropriate security fix.

If immediate remediation is not possible, consider temporarily isolating the affected application from public access or restricting access to trusted networks while the update is prepared.

A web application firewall may provide an additional defensive layer, but it is not a replacement for a patched runtime.

PHP's interim guidance includes configuration changes that can reduce exposure in certain circumstances. However, these measures are incomplete and must not be treated as proof that an unpatched installation is safe.

For production systems, consult the official advisory and have a qualified administrator assess the appropriate temporary controls.

9. How to Investigate a Potential Compromise

A vulnerable version does not automatically mean an attacker has compromised the server. However, an internet-facing system that remained vulnerable should be assessed carefully.

Review:

Web server and PHP application logs.
Authentication and administrative activity.
Unexpected files or modified application code.
Unknown scheduled tasks or processes.
Unexpected outbound network connections.
Changes to application configuration files.
Suspicious access to credentials or sensitive data.

Look for activity around the period when the system was exposed, and preserve relevant logs before making changes that could destroy evidence.

If there is credible evidence of compromise, isolate the affected system where appropriate and follow your incident-response process. Patching alone may not remove a backdoor or reverse unauthorized changes.

Do not publish sensitive logs or credentials while requesting assistance.

10. What Hosting Providers Should Do

Hosting providers have a particular responsibility because one server can serve many customer websites.

A practical response should include:

Inventorying affected PHP installations.
Identifying domains using vulnerable runtimes.
Updating system packages or applying verified vendor backports.
Restarting services and verifying loaded versions.
Reviewing monitoring and security logs.
Checking container images and bundled PHP runtimes.
Communicating clearly with customers.
Maintaining backups and incident-response procedures.

For shared hosting, customers may not have the privileges required to update the server-level PHP runtime themselves. In that situation, the provider should confirm the patch status and explain any required customer-side actions.

At Puffx Host, we encourage website owners to verify their PHP versions and work with their hosting provider to resolve any outstanding security issues.

Read our full report: PHP2Shell: Critical PHP Flaw — Update Now

11. Developer Checklist

Before closing your PHP2Shell remediation task, confirm the following:

[ ] All PHP installations have been inventoried.
[ ] Internet-facing systems have been prioritized.
[ ] The correct security-fixed package or verified backport has been installed.
[ ] PHP-FPM, Apache, or other relevant services are running the fixed code.
[ ] Containers and bundled PHP runtimes have been checked.
[ ] WordPress, plugins, frameworks, and dependencies have been reviewed.
[ ] Logs have been examined for signs of compromise.
[ ] Backups and recovery procedures have been verified.
[ ] Application functionality has been tested.
[ ] Remaining vulnerable systems have been isolated or have a documented remediation plan.

Conclusion

PHP2Shell highlights an important lesson in secure software engineering: application security depends on the entire stack, including the runtime, operating system, dependencies, and server configuration.

Developers should verify official advisories and apply the appropriate security updates. DevOps teams should inventory their infrastructure and confirm that running services use the fixed packages. Hosting providers should prioritize exposed systems and communicate clearly with customers.

Security maintenance is not a one-time task. It requires ongoing monitoring, timely updates, and a clear incident-response process.

At Puffx Host, we believe reliable hosting begins with responsible infrastructure management, security awareness, and proactive maintenance.

Keep your runtime patched. Monitor your infrastructure. Protect your applications.

Official References

About Puffx Host

Puffx Host provides web hosting services designed to help businesses and developers run their websites and applications.

Website: https://puffxhost.com

For security guidance and related updates, visit our PHP2Shell security article.

Editorial note: Technical details and release information in this article are based on the cited advisories available at the time of writing. Always consult the current official guidance for your specific environment.

php #security #webdev #devops

Best Web Hosting in 2026: Top 20 Hosting Providers Compared

Nitin Mehta — Tue, 20 Oct 2026 07:54:43 +0000

Best Web Hosting in 2026: Top 20 Hosting Providers Compared

Choosing a web hosting provider is one of the most important decisions when launching a website, blog, online store, SaaS product, or business application.

A hosting provider affects more than just your website's loading speed. It also influences security, uptime, scalability, technical flexibility, customer support, and the total cost of running your project.

But with so many hosting companies available, how do you decide which one is right for you?

In this guide, we'll compare 20 hosting providers, explain what each one is best suited for, and help you understand what to check before purchasing a hosting plan.

Disclosure: This article is published by Puffx Host. Puffx Host is our own hosting service and is included as one of the options. The rankings are an editorial comparison, not the result of a controlled benchmark of every provider. Pricing, features, and availability can change, so verify the current plan details before purchasing.

What makes a good web hosting provider?
Top 20 web hosting providers in 2026
Hosting comparison table
How to choose the right hosting
Common hosting mistakes
Frequently asked questions
Final thoughts

1. What Makes a Good Web Hosting Provider?

Before comparing companies, understand the factors that actually matter.

Performance and loading speed

A fast website provides a better user experience. Server resources, storage technology, caching, PHP configuration, database performance, and server location can all affect response times.

For an audience primarily in India, compare the available server locations and test latency from your target region.

Uptime and reliability

Uptime represents the percentage of time a service remains available.

A 99.9% uptime target allows approximately 8 hours and 46 minutes of downtime over a 365-day year. A published uptime commitment is not the same as independently measured performance, so check the provider's service-level agreement and exclusions.

Security

Look for SSL/TLS certificates, security updates, account isolation, malware protection, backup options, and a clear recovery process.

Remember that SSL alone does not make a website completely secure. Your application, passwords, plugins, and server configuration also matter.

Pricing and renewal costs

A low introductory price can be attractive, but always compare the renewal price, billing period, taxes, domain renewal, backup fees, and migration costs.

The cheapest first payment is not necessarily the cheapest long-term solution.

Customer support

Beginners may need help with DNS configuration, SSL installation, email setup, database creation, WordPress installation, or application deployment.

Check support hours, available contact channels, response commitments, and whether technical assistance is included in your plan.

2. Top 20 Web Hosting Providers in 2026

The following list is a practical shortlist organized around different use cases. The order should not be treated as a verified global performance ranking; the best option depends on your requirements, location, and budget.

1. Puffx Host — An Option for Indian Customers

Best for: Budget-conscious users looking for hosting with direct support.

Puffx Host focuses on affordable hosting services and support for customers who want to establish an online presence without managing an entire server themselves.

It may be worth considering if you prefer assistance with basic hosting setup, domain configuration, SSL, and website deployment.

Before purchasing, compare the exact plan specifications, resource limits, backup policy, uptime commitment, and support scope with other providers.

Explore plans: https://puffxhost.com/packages

2. Hostinger — Beginner-Friendly Hosting

Best for: Beginners, personal websites, and small businesses.

Hostinger offers shared hosting, WordPress hosting, cloud hosting, and other website services. Its control panel and website-building tools can make getting started easier for people without server administration experience.

Compare the current plan's storage, number of websites, backup schedule, renewal price, and available server locations before choosing a package.

Website: https://www.hostinger.com/

3. Bluehost — WordPress Websites

Best for: WordPress beginners and small business websites.

Bluehost provides hosting products designed for websites and WordPress-based projects. It is worth comparing if you want a conventional hosting setup rather than managing your own server.

Check the current WordPress recommendations, renewal costs, resource limits, and included support before buying.

Website: https://www.bluehost.com/

4. SiteGround — Managed Website Hosting

Best for: Users who prioritize managed services and support.

SiteGround offers managed WordPress and other website hosting products. Its tooling can reduce the amount of server administration required for supported websites.

It may cost more than entry-level hosting, so evaluate whether the included features justify the price for your project.

Website: https://www.siteground.com/

5. HostGator — General-Purpose Hosting

Best for: Small websites and conventional hosting requirements.

HostGator offers hosting services for websites, including shared hosting options. It is an option for users who want a standard hosting environment.

Review the current storage, backup, resource, and renewal policies rather than relying on broad claims such as unlimited resources.

Website: https://www.hostgator.com/

6. DreamHost — Websites and WordPress

Best for: Personal websites, blogs, and WordPress projects.

DreamHost provides shared, managed WordPress, VPS, and other hosting products. Different plans have different limits, so check how many websites you can host and which resources are included.

Website: https://www.dreamhost.com/

7. A2 Hosting / Hosting.com — Performance-Focused Hosting

Best for: Users comparing performance-oriented hosting plans.

A2 Hosting is a familiar name in the performance-hosting market, although its branding and service offering have evolved. Check the current provider identity and product terms before purchasing.

Compare PHP performance, caching, CPU limits, memory, and server location rather than relying on a marketing label such as “Turbo.”

Website: https://hosting.com/

8. InMotion Hosting — Business and Reseller Hosting

Best for: Businesses and users considering reseller hosting.

InMotion Hosting offers several hosting categories, including business-oriented services and reseller products.

If you plan to host multiple customer websites, compare account limits, resource allocation, billing tools, backups, and the amount of technical administration required.

Website: https://www.inmotionhosting.com/

9. GreenGeeks — Environmentally Focused Hosting

Best for: Users who care about environmental initiatives.

GreenGeeks markets hosting services with an emphasis on environmental sustainability. It also offers conventional website hosting features.

Review the provider's current sustainability disclosures alongside its performance, pricing, backup policy, and support terms.

Website: https://www.greengeeks.com/

10. Kinsta — Premium Managed WordPress

Best for: Businesses that want managed WordPress infrastructure.

Kinsta focuses on managed WordPress hosting and provides tools designed to simplify deployment, maintenance, and website management.

It is generally a different budget category from entry-level shared hosting. Compare visitor limits, resource policies, included environments, backups, and additional-site costs.

Website: https://kinsta.com/

11. Cloudways — Managed Cloud Hosting

Best for: Growing websites that need cloud infrastructure.

Cloudways provides a managed interface for deploying applications on supported cloud infrastructure providers.

It can reduce server-management complexity, but it does not eliminate the need to understand application performance, backups, security, and resource usage.

Website: https://www.cloudways.com/

12. Namecheap — Domains and Budget Hosting

Best for: Users purchasing domains and hosting together.

Namecheap is known for domain registration and also offers hosting products.

Compare the total cost of domain renewal and hosting renewal, not just the introductory price. Check email, backups, migration options, and resource limits as well.

Website: https://www.namecheap.com/

13. IONOS — Small Business Hosting

Best for: Small businesses evaluating website and cloud services.

IONOS offers several hosting and website services, with product availability varying by market.

Compare the exact plan configuration, contract period, support availability, and renewal pricing for your country.

Website: https://www.ionos.com/

14. GoDaddy — Domains and Website Services

Best for: Users who want domain registration and hosting services from one provider.

GoDaddy provides domain registration, website tools, hosting, and other online business services.

Its broad product range can be convenient, but compare hosting performance, renewal costs, backups, and add-on fees with competing providers.

Website: https://www.godaddy.com/

15. InterServer — Traditional Hosting

Best for: Users comparing conventional hosting plans and pricing policies.

InterServer offers hosting services across several categories. It may be worth comparing if you want a traditional hosting environment.

Read the exact price-lock terms, resource limits, server locations, and support conditions applicable to your selected product.

Website: https://www.interserver.net/

16. Liquid Web — Managed VPS and Dedicated Infrastructure

Best for: Businesses with demanding infrastructure requirements.

Liquid Web focuses on managed hosting and infrastructure services for businesses and more resource-intensive applications.

It is worth evaluating when you need more control or managed server resources than an entry-level shared plan can provide.

Website: https://www.liquidweb.com/

17. DigitalOcean — Cloud Servers for Developers

Best for: Developers deploying custom applications.

DigitalOcean offers cloud infrastructure and managed services. It is useful for developers who need control over virtual machines, networking, databases, and application deployment.

However, a virtual machine is not the same as fully managed shared hosting. You may need to configure security updates, firewalls, web servers, monitoring, backups, and application dependencies yourself.

Website: https://www.digitalocean.com/

18. Vultr — Flexible Cloud Infrastructure

Best for: Developers and teams needing configurable cloud servers.

Vultr offers cloud computing products with different server configurations and deployment options.

Compare CPU type, RAM, storage, bandwidth, network performance, backups, and regional availability before selecting an instance.

Website: https://www.vultr.com/

19. AWS — Scalable Cloud Infrastructure

Best for: Applications that need a broad cloud services ecosystem.

Amazon Web Services offers computing, storage, databases, networking, and many other cloud products.

Its flexibility is powerful, but costs and configuration complexity can increase if you do not understand resource usage, security permissions, and billing.

For a simple blog, AWS may be unnecessarily complicated. For a growing application, its range of services may be useful.

Website: https://aws.amazon.com/

20. Google Cloud — Cloud Applications and Infrastructure

Best for: Developers building scalable applications and data-driven services.

Google Cloud offers virtual machines, managed databases, storage, networking, and application development services.

Evaluate expected usage, networking charges, regional availability, security requirements, and operational complexity before moving a production application.

Website: https://cloud.google.com/

3. Hosting Comparison: Which Type Should You Choose?

Hosting type	Best suited for	Main consideration
Shared hosting	Blogs and small websites	Shared server resources
Managed WordPress	WordPress sites	Convenience versus cost
Reseller hosting	Hosting businesses	Account and resource limits
VPS hosting	Custom applications	More administration
Managed cloud hosting	Growing websites	Recurring infrastructure costs
Cloud infrastructure	Developers and larger applications	Configuration and operational responsibility

There is no universal winner. A small portfolio website and a high-traffic application have very different hosting requirements.

4. How to Choose the Right Hosting Provider

Step 1: Identify your website type

Start by identifying the software you will run.

WordPress blog: Look for suitable PHP, database, caching, and backup support.
Laravel application: Check PHP version, required extensions, Composer availability, SSH access, cron jobs, and document-root configuration.
Online store: Prioritize security, backups, reliable database performance, and payment-system compatibility.
Custom Node.js application: Confirm whether the plan supports Node.js processes, deployment, and persistent application execution.
Multiple customer websites: Compare reseller hosting or VPS options.

Step 2: Estimate resource requirements

Do not buy a large server simply because a provider advertises more CPU cores.

Consider your expected traffic, concurrent requests, database workload, storage, background jobs, and memory consumption. Start with a suitable configuration and monitor actual usage.

Step 3: Check the full cost

Calculate the cost for at least the first year and, if possible, the second year.

Include hosting renewal, domain renewal, backups, email, paid SSL options if applicable, migrations, and any required server-management services.

Step 4: Verify technical compatibility

Before ordering, confirm:

Supported PHP or Node.js versions.
Required PHP extensions and database versions.
SSH or terminal availability.
Composer and deployment support.
Cron-job limits and execution frequency.
File, process, CPU, memory, and inode limits.
SSL issuance and renewal.
Backup retention and restoration procedure.

These checks can prevent expensive migrations later.

Step 5: Test support before committing

Ask a specific pre-sales question about your intended application. Evaluate how clearly the provider explains compatibility, limitations, and what its support team will actually configure.

A vague promise of “full support” is not a substitute for a written support scope.

5. Common Web Hosting Mistakes

Choosing only by price: A low initial payment can hide expensive renewals or missing features.

Ignoring backups: A backup is useful only if it can be restored successfully. Check retention and restoration procedures.

Buying VPS hosting without the skills to manage it: Root access gives you control, but it also makes you responsible for more security and maintenance tasks.

Ignoring server location: Physical distance, routing, and network quality can affect latency for your visitors.

Assuming unlimited means unlimited: Most plans have acceptable-use policies and technical limits. Read the terms.

Skipping security updates: Outdated application dependencies and plugins can compromise a properly configured server.

Migrating without testing: Always maintain a backup and test DNS, email, databases, SSL, and application behavior before switching production traffic.

6. Frequently Asked Questions

Which hosting is best for beginners in 2026?

A beginner should generally look for easy setup, clear documentation, suitable support, automatic SSL, backups, and transparent renewal pricing. Shared hosting or managed WordPress hosting is often a reasonable starting point.

Which hosting is suitable for WordPress?

Managed WordPress hosting can simplify maintenance, while standard shared hosting can be more affordable. The right choice depends on traffic, technical requirements, budget, and the support included.

Is VPS hosting better than shared hosting?

Not automatically. VPS hosting can provide more control and dedicated resource allocations, depending on the plan. Shared hosting is often simpler and more economical for smaller websites.

Can I host a Laravel application on shared hosting?

Sometimes. You need compatible PHP versions and extensions, Composer or another supported deployment method, database access, cron support where required, and a secure document root. Verify these requirements before buying.

Is cheap hosting reliable?

Price alone does not determine reliability. Review the actual resource limits, support terms, backups, uptime commitment, renewal costs, and independent performance evidence.

Should I choose Indian hosting for Indian visitors?

A suitable Indian server location may reduce network latency for Indian visitors, but routing, caching, application performance, and server quality also matter. Test from your target audience's region when possible.

How often should I back up my website?

It depends on how frequently your website changes and how much data you can afford to lose. A store receiving orders every few minutes needs a more rigorous backup and recovery strategy than a static portfolio site.

7. Final Thoughts

Choosing web hosting is not about finding the company with the biggest name or the lowest advertised price. It is about finding the right balance of performance, security, support, cost, and technical compatibility for your project.

For a simple blog, shared hosting may be enough. For WordPress, managed hosting may save time. For a custom application, a VPS or cloud platform may offer the flexibility you need.

Compare the actual plans, check the terms, and make your decision based on your requirements rather than a ranking alone.

If you are exploring affordable hosting for your next website, you can review Puffx Host's available plans here:

Explore Puffx Host: https://puffxhost.com/packages

Have you used any of these hosting providers? Share your experience, including performance, support quality, renewal pricing, and any limitations you encountered. Real-world experiences can help other developers make better decisions.

Disclaimer: Hosting features, prices, and service availability can change. Verify current terms directly with each provider. Puffx Host is the publisher's own service; readers should compare it independently with other options.
`

plaintext`



`
`
`

I Built a Multimodal RAG System with Gemini File Search — Here’s What I Learned

Nitin Mehta — Tue, 25 Aug 2026 11:03:10 +0000

I Built a Multimodal RAG System with Gemini File Search — Here’s What I Learned

RAG has become one of the most practical ways to build AI applications that need to work with private or domain-specific information.

Instead of expecting an LLM to already know everything, we can give it access to our own documents and retrieve the relevant information when a user asks a question.

That sounds simple until the data stops being simple.

Real-world knowledge bases rarely contain only plain text. They can contain PDFs, screenshots, product images, diagrams, tables, architecture documents, technical manuals, and other visual information.

That was the problem I wanted to solve.

I wanted a RAG system where text and images could live in the same searchable knowledge base instead of maintaining separate pipelines for documents and visual data.

This is where Gemini API File Search becomes interesting.

Google's Gemini API provides File Search as a managed Retrieval-Augmented Generation system. It handles the ingestion, chunking, embedding, indexing, and retrieval pipeline, while the model uses the retrieved information to generate a grounded response. The newer multimodal capabilities extend this workflow to images as well.

In this article, I'll walk through how I think about the architecture, why multimodal embeddings matter, how the implementation works, and where this approach makes sense compared with building a traditional RAG stack yourself.

What Problem Does RAG Actually Solve?

A normal LLM has a knowledge boundary.

Even if the model is extremely capable, it doesn't automatically have access to your company's internal documentation, private PDFs, product catalog, support tickets, or architecture diagrams.

You could fine-tune a model, but that is often the wrong solution.

If the information changes frequently, you don't want to retrain a model every time a document changes.

RAG solves this differently.

Instead of modifying the model's knowledge, you retrieve relevant information from an external knowledge source and provide that information as context to the model.

The basic workflow looks like this:

User Question
     ↓
Convert Question to Search Representation
     ↓
Search Knowledge Base
     ↓
Retrieve Relevant Chunks
     ↓
Send Retrieved Context to LLM
     ↓
Generate Grounded Answer

This is powerful because the knowledge can be updated without retraining the model.

But traditional RAG becomes more complicated when your knowledge isn't purely text.

Consider a technical PDF containing:

Written documentation
Architecture diagrams
Screenshots
Tables
Product images
Flow charts

If your retrieval system only understands extracted text, you may lose valuable information contained inside those visual elements.

That's where multimodal retrieval changes the architecture.

Why Multimodal RAG Is Different

Traditional text RAG generally converts text into embeddings.

Those embeddings represent the semantic meaning of the text.

A user query is also converted into an embedding, and the system searches for chunks that are semantically similar.

Multimodal RAG extends this idea beyond text.

With Gemini's gemini-embedding-2, images can also be embedded and searched alongside textual content. This means an application can retrieve visual information rather than relying entirely on OCR or manually generated image descriptions.

For example, imagine a product catalog containing:

Product description
+
Product specifications
+
Product image

A user could ask:

"Show me the product that has a red design."

A multimodal retrieval system can search the visual representation of the product image along with the associated textual information.

That opens up use cases that are difficult to implement cleanly with text-only RAG.

The Architecture I Would Use

The architecture is surprisingly small when using managed File Search.

                 ┌──────────────────────┐
                 │   Documents / Images  │
                 └──────────┬───────────┘
                            ↓
                 ┌──────────────────────┐
                 │   File Search Store  │
                 │                      │
                 │ Chunking              │
                 │ Embeddings            │
                 │ Indexing              │
                 └──────────┬───────────┘
                            ↓
User Question ─────────────→ Semantic Search
                            ↓
                    Relevant Context
                            ↓
                     Gemini Model
                            ↓
                    Grounded Response
                            ↓
                         Citations

The important part is that I don't have to manually operate a vector database, embedding service, document chunking pipeline, and retrieval layer.

File Search manages those parts for me.

Google describes a File Search Store as a persistent container for processed document data and embeddings. When files are imported, the content is chunked, converted into embeddings, and indexed for semantic retrieval.

That removes a significant amount of infrastructure from the application.

Creating a Multimodal File Search Store

The first important decision is the embedding model.

If you're building a text-only knowledge base, the text embedding model may be sufficient.

But if you want native image retrieval, the File Search Store needs to be created using:

models/gemini-embedding-2

For example:

from google import genai

client = genai.Client()

store = client.file_search_stores.create(
    config={
        "display_name": "my-multimodal-knowledge-base",
        "embedding_model": "models/gemini-embedding-2"
    }
)

print(store.name)

This decision matters because the embedding model is associated with the store configuration.

So don't blindly create a store with the default embedding model and later discover that your application needs multimodal retrieval.

Google's current documentation specifically recommends gemini-embedding-2 for processing both text and images in a multimodal File Search Store.

Uploading Documents

Once the store exists, documents can be uploaded directly.

For example:

import time

operation = client.file_search_stores.upload_to_file_search_store(
    file_search_store_name=store.name,
    file="technical-documentation.pdf",
    config={
        "display_name": "Technical Documentation"
    }
)

while not operation.done:
    time.sleep(5)
    operation = client.operations.get(operation)

print("Document indexed")

Behind the scenes, the service processes the document and prepares it for retrieval.

The important thing for developers is that we don't need to manually implement every stage of the ingestion pipeline.

Instead of writing:

PDF parser
      ↓
Text extraction
      ↓
Chunking service
      ↓
Embedding API
      ↓
Vector database
      ↓
Metadata layer
      ↓
Retriever

we can work with the managed File Search abstraction.

That can significantly reduce development and operational overhead.

Adding Images

This becomes more interesting with multimodal stores.

Images can also be uploaded:

images = [
    "product-red.png",
    "product-blue.png",
    "architecture-diagram.png"
]

for image_file in images:

    operation = client.file_search_stores.upload_to_file_search_store(
        file_search_store_name=store.name,
        file=image_file,
        config={
            "display_name": image_file
        }
    )

    while not operation.done:
        time.sleep(5)
        operation = client.operations.get(operation)

Google's current documentation states that PNG and JPEG images are supported for multimodal File Search, with an image resolution limit of 4K × 4K pixels. Audio and video are currently not supported by File Search.

That last limitation is important.

Multimodal does not mean "every media format."

You should design your ingestion pipeline around the formats File Search actually supports.

Querying the Knowledge Base

After indexing the data, the actual application logic becomes simple.

The model can use File Search as a tool:

response = client.models.generate_content(
    model="gemini-3-flash-preview",
    contents="Which product is available in red?",
    config={
        "tools": [{
            "file_search": {
                "file_search_store_names": [store.name]
            }
        }]
    }
)

print(response.text)

The query is converted into a representation that can be matched against the indexed content.

The retrieval system then finds relevant chunks from the File Search Store.

Those results are supplied as context for the model.

The model generates an answer based on the retrieved information rather than relying exclusively on its general knowledge.

That distinction is extremely important.

RAG doesn't magically make an LLM truthful.

It gives the model access to better evidence.

Semantic Search Instead of Keyword Search

One reason this architecture is useful is semantic search.

Consider a document containing:

"Our infrastructure automatically increases compute capacity when traffic exceeds predefined thresholds."

A user might ask:

"How does the system handle traffic spikes?"

A basic keyword search might struggle because "traffic spikes" doesn't exactly match the original wording.

Semantic retrieval is designed to understand the relationship between the query and the underlying meaning.

Gemini File Search uses embeddings to represent the semantic meaning of indexed content and retrieve relevant chunks based on the user's prompt.

This is one of the fundamental reasons RAG systems are more useful than simple text search.

Metadata Makes Retrieval More Useful

Another feature I would use in a real application is metadata.

Suppose the same knowledge base contains documents from different categories:

product
support
engineering
billing
legal

Instead of searching everything every time, metadata can help narrow the retrieval scope.

For example:

config={
    "display_name": "Spring Product Catalog",
    "custom_metadata": [
        {
            "key": "category",
            "string_value": "product"
        },
        {
            "key": "season",
            "string_value": "spring-2026"
        }
    ]
}

Then the query can use a metadata filter.

This matters because retrieval quality isn't only about the embedding model.

The quality of your data organization also matters.

A huge unstructured knowledge base can produce weaker retrieval than a well-organized one.

Citations Are More Important Than They Look

One of the biggest problems with AI-generated answers is verification.

If the model says:

"This product supports feature X."

I want to know where that information came from.

File Search provides grounding information that can identify the source material used to generate the response. Depending on the response and API surface, this can include document/page information or other citation metadata.

This changes the UX of a RAG application.

Instead of:

AI says something.

you can build:

AI says something.

Source:
Technical Documentation
Page 14

For enterprise applications, this can be far more valuable than simply generating a fluent response.

A good RAG system should make it easier to verify the answer.

RAG Does Not Automatically Fix Hallucinations

This is where many RAG tutorials oversell the technology.

Adding a vector database does not guarantee correct answers.

There are several failure points:

Bad document
    ↓
Bad chunking
    ↓
Bad embedding
    ↓
Bad retrieval
    ↓
Wrong context
    ↓
Wrong answer

The LLM is only the final stage.

If retrieval returns irrelevant information, the model can still generate a confident-looking answer.

That's why I would test a RAG system with an evaluation dataset instead of judging it from five successful demos.

Create questions where you already know:

The correct answer
The source document
The expected section/page
Whether the answer should exist at all

Then measure retrieval and answer quality.

Chunking Still Matters

Managed retrieval doesn't mean chunking becomes irrelevant.

A document can be split into chunks before embedding.

If chunks are too large, retrieval can become less precise.

If chunks are too small, important context can be separated.

Google's File Search API also supports custom chunking configuration. For example, the documentation demonstrates configuring a whitespace-based strategy with a maximum number of tokens per chunk and overlap between chunks.

For example:

"chunking_config": {
    "white_space_config": {
        "max_tokens_per_chunk": 200,
        "max_overlap_tokens": 20
    }
}

I wouldn't copy these numbers blindly into production.

Chunking should be tested against your actual documents.

Technical manuals, legal documents, product catalogs, and source-code documentation don't necessarily benefit from the same chunking strategy.

Where Multimodal RAG Becomes Really Useful

This architecture is particularly interesting for applications where visual information carries meaning.

Technical Documentation

Imagine a developer asking:

"Find the architecture diagram that shows the authentication flow."

A text-only system may retrieve a paragraph describing authentication.

A multimodal system can also work with the actual diagram.

Product Catalogs

A product database can combine:

Product name
Description
Specifications
Price information
Product images

Users can search using both natural language and visual characteristics.

Real Estate

A property knowledge base can contain:

Property descriptions
Floor plans
Interior images
Specifications

The retrieval layer can work with more than just text.

Design Systems

Imagine indexing UI screenshots, component documentation, and design specifications.

A developer could search for a component based on its visual appearance or associated documentation.

These are the situations where multimodal retrieval becomes more than a marketing feature.

What About Cost?

Cost is another reason managed File Search is interesting.

According to Google's current documentation, storage and query-time embedding generation are free. You pay for embedding creation when files are initially indexed, along with normal Gemini model input/output token usage. Retrieved document tokens are charged as regular context tokens.

That doesn't mean the system is free.

Large knowledge bases still create indexing and model-token costs.

You should monitor:

Number of indexed files
+
Indexing frequency
+
Retrieved context size
+
Model requests
+
Response tokens

A poorly designed application can retrieve too much context and increase token usage unnecessarily.

The goal isn't to retrieve everything.

The goal is to retrieve the smallest useful amount of evidence needed to answer the question.

Important Limits

Production systems also need to respect service limits.

Google's current File Search documentation lists a maximum individual document size of 100 MB. Project-level File Search storage limits vary by usage tier, and Google recommends keeping individual stores under 20 GB for better retrieval latency.

There are also feature limitations.

For example, File Search isn't currently supported in the Live API, and built-in grounding tools have compatibility restrictions when combined in the same request.

These details are easy to ignore in a demo and painful to discover in production.

When I Would Use File Search Instead of Building My Own RAG Stack

I wouldn't say managed File Search replaces every vector database.

It doesn't.

If I need highly customized retrieval logic, specialized ranking, complex hybrid search, or complete infrastructure control, I may still build a custom RAG architecture.

But if my goal is:

Upload documents
        ↓
Index them
        ↓
Search them semantically
        ↓
Ask Gemini questions
        ↓
Return grounded answers

then a managed solution can remove a lot of unnecessary infrastructure.

I don't have to maintain:

My own vector database
Embedding workers
Chunking pipelines
Retrieval services
Index synchronization
Separate image retrieval infrastructure

That can mean fewer moving parts and less code to maintain.

The Architecture I Would Build for a Real Application

For a production application, I'd put an application layer in front of File Search.

                User
                 │
                 ▼
          Web / Mobile App
                 │
                 ▼
             API Server
                 │
        ┌────────┴─────────┐
        │                  │
        ▼                  ▼
 Authentication       Query Validation
                           │
                           ▼
                    Gemini File Search
                           │
                           ▼
                    Retrieved Context
                           │
                           ▼
                     Gemini Model
                           │
                           ▼
                Answer + Citations
                           │
                           ▼
                       User

The API server should control access.

Users shouldn't automatically get access to every document in every store.

I'd separate stores or use metadata according to the application's authorization model.

For example:

Company A
 ├── Engineering
 ├── Support
 └── Product

Company B
 ├── Engineering
 ├── Support
 └── Product

This becomes especially important when the RAG system contains private business information.

My Biggest Takeaway

The most interesting part of modern RAG isn't simply that an LLM can "chat with PDFs."

That's old news.

The bigger shift is that retrieval is becoming multimodal and increasingly managed.

Documents aren't just text.

Knowledge can exist inside:

Diagrams
Screenshots
Images
Tables
Product photos
Technical documentation

A retrieval system that ignores those formats is potentially throwing away useful information.

Gemini File Search's multimodal support makes it possible to build a single retrieval workflow around both text and images, while managed indexing, semantic search, metadata, and citations reduce the amount of infrastructure developers need to operate themselves.

But I wouldn't treat it as a magic "add RAG and everything works" button.

The real engineering work is still in:

Data quality
     ↓
Document organization
     ↓
Chunking
     ↓
Metadata
     ↓
Retrieval evaluation
     ↓
Prompt design
     ↓
Access control
     ↓
Answer verification

The technology can handle much of the infrastructure.

It cannot decide what good data looks like for your application.

Final Thoughts

If you're building a knowledge-based AI application today, I think the right question isn't:

"Which vector database should I use?"

The better first question is:

"How much retrieval infrastructure do I actually need to own?"

For many applications, a managed File Search system can get you from a folder full of documents to a grounded AI assistant much faster.

And when the data includes images and diagrams, multimodal retrieval makes the architecture considerably more useful.

The best RAG system isn't the one with the most components.

It's the one that retrieves the right evidence, gives the model enough context to reason over it, and makes the final answer easy to verify.

That's the part that actually matters in production.

How I Automated cPanel Hosting Management Using APIs

Nitin Mehta — Tue, 25 Aug 2026 10:58:23 +0000

How I Automated cPanel Hosting Management Using APIs

Managing hosting accounts manually works when you have a few customers.

Once you start managing dozens or hundreds of hosting accounts, it becomes a completely different problem.

Creating accounts, assigning packages, suspending users, changing plans, checking disk usage, managing domains, creating databases, handling backups, and performing repetitive server operations manually takes a lot of time.

It also creates another problem: human error.

I wanted to solve this by putting an automation layer between my hosting management system and cPanel.

Instead of logging into cPanel every time I needed to perform an operation, I started using the cPanel APIs to communicate with the server programmatically.

The result was a much more scalable workflow where my application could perform hosting operations automatically. This kind of automation is especially useful when running a hosting business, such as a web hosting platform in India, where provisioning and account lifecycle operations can quickly become repetitive.

In this article, I’ll explain the architecture, API authentication, PHP integration, account management, error handling, security considerations, and some of the lessons I learned while building this type of system.

Why Automate cPanel?

The first question is simple:

Why not just use cPanel manually?

For a small number of accounts, manual management is perfectly fine.

But imagine having to perform these operations repeatedly:

Create a hosting account
Assign a hosting package
Create an email account
Add a domain
Create a database
Suspend an account
Unsuspend an account
Change an account's package
Check disk usage
Check bandwidth usage
Generate backups
Delete an account
Update DNS records
Retrieve account information

Doing this manually is slow.

More importantly, manual processes don't scale.

If a customer purchases a hosting package from a billing system, there is no reason for an administrator to manually create the account on cPanel.

The application should be able to do it automatically.

That's where APIs become useful.

The Basic Architecture

The architecture I use is based on a simple concept:

Customer
   |
   v
Billing / Client Panel
   |
   v
Automation Layer
   |
   v
cPanel API
   |
   v
Hosting Server

The customer interacts with the client panel.

The client panel handles the business logic.

The automation layer communicates with cPanel.

cPanel performs the actual server operation.

This separation is important because I don't want my frontend directly communicating with the hosting server.

Instead, all API communication goes through a controlled backend service.

Understanding cPanel APIs

cPanel provides APIs that allow applications to perform many operations programmatically.

There are two important API levels:

UAPI

UAPI is primarily used for account-level operations.

For example:

Email management
Database management
Domain management
File-related operations
Account information
SSL-related operations
Other cPanel account functions

WHM API

WHM API is used for server and account administration.

For example:

Creating hosting accounts
Suspending accounts
Unsuspending accounts
Terminating accounts
Managing packages
Managing reseller accounts
Server-level operations

The important thing to understand is that UAPI and WHM API solve different problems.

If I need to create a new hosting account, I generally need WHM-level permissions.

If I need to perform an operation inside an existing cPanel account, UAPI is often the appropriate choice.

Getting API Access

Before writing any automation code, I need an API token.

On a cPanel/WHM server, API access can be configured through the appropriate management interface.

The general process is:

Log in to WHM or cPanel.
Open the API token management section.
Create a dedicated API token.
Give the token only the permissions it actually needs.
Store the token securely.
Use the token from the backend application.

The API token should be treated like a password.

Never put it directly inside frontend JavaScript.

Never expose it in HTML.

Never commit it to GitHub.

For example, this is a bad idea:

$apiToken = "my-secret-api-token";

A better approach is to store sensitive credentials in environment variables or a secure configuration system.

For example:

$apiToken = getenv('CPANEL_API_TOKEN');

This keeps the secret outside the application source code.

Connecting PHP to cPanel

Since much of my hosting automation work is backend-based, PHP is a natural choice for communicating with cPanel APIs.

PHP's cURL support makes HTTP API communication relatively straightforward.

A basic API client can look like this:

<?php

function cpanelRequest(
    string $url,
    string $token,
    string $method = 'GET',
    array $data = []
) {
    $ch = curl_init();

    curl_setopt_array($ch, [
        CURLOPT_URL => $url,
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CUSTOMREQUEST => $method,
        CURLOPT_HTTPHEADER => [
            "Authorization: cpanel $token"
        ],
        CURLOPT_TIMEOUT => 30,
        CURLOPT_CONNECTTIMEOUT => 10,
    ]);

    if (!empty($data)) {
        curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query($data));
    }

    $response = curl_exec($ch);

    if ($response === false) {
        throw new Exception(curl_error($ch));
    }

    $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);

    curl_close($ch);

    return [
        'status' => $httpCode,
        'body' => json_decode($response, true)
    ];
}

This isn't the entire automation system.

It's simply the communication layer.

The important idea is to create one reusable API client instead of writing separate cURL code everywhere.

Don't Repeat API Code Everywhere

One mistake I see in automation projects is writing API calls directly inside every business function.

For example:

createAccount()

contains cURL code.

Then:

suspendAccount()

contains another cURL implementation.

Then:

deleteAccount()

contains another implementation.

This becomes difficult to maintain.

Instead, I prefer creating an API client.

For example:

class CpanelClient
{
    private string $baseUrl;
    private string $token;

    public function __construct(
        string $baseUrl,
        string $token
    ) {
        $this->baseUrl = rtrim($baseUrl, '/');
        $this->token = $token;
    }

    public function request(
        string $endpoint,
        string $method = 'GET',
        array $data = []
    ): array {
        // API communication here
    }
}

Now the rest of the application doesn't need to know how authentication, HTTP requests, or JSON parsing work.

It simply calls methods on the client.

Automating Hosting Account Creation

One of the most useful automations is account provisioning.

Imagine a customer purchases a hosting plan.

The workflow can become:

Payment Successful
       |
       v
Create Hosting Account
       |
       v
Assign Package
       |
       v
Configure Domain
       |
       v
Create Database
       |
       v
Send Login Details

Without automation, an administrator might have to perform each step manually.

With an API-driven system, the backend can trigger the process automatically.

Conceptually:

$account = [
    'username' => 'customer123',
    'domain'   => 'example.com',
    'password' => $generatedPassword,
    'package'  => 'Business'
];

$result = $cpanel->createAccount($account);

The actual API endpoint and parameters depend on the cPanel/WHM API version and your server configuration.

That's important because blindly copying an API example from an old blog post can cause problems.

Always verify the endpoint and parameters against the API documentation for the version you're running.

Automating Suspension and Unsuspension

Another useful automation is account lifecycle management.

For example, if a hosting invoice becomes overdue, your billing system can trigger:

Invoice Overdue
      |
      v
Check Grace Period
      |
      v
Suspend Account

When payment is received:

Payment Received
      |
      v
Verify Payment
      |
      v
Unsuspend Account

This eliminates a lot of manual work.

However, I would not immediately suspend an account just because an API call says an invoice is overdue.

The billing system should have its own rules.

For example:

Invoice overdue
       ↓
Grace period
       ↓
Payment reminder
       ↓
Final warning
       ↓
Suspension

The API should perform the server operation.

It should not decide your entire business policy.

Automating Package Changes

Suppose a customer upgrades from a basic hosting package to a business package.

Instead of asking an administrator to log into WHM, find the account, select the new package, and save the changes, the application can call the relevant API.

The workflow becomes:

Customer Upgrade
       |
       v
Payment Confirmed
       |
       v
Update Hosting Package
       |
       v
Record API Result
       |
       v
Notify Customer

This becomes particularly powerful when connected to a billing platform. The same model can be useful for reseller hosting, where many customer cPanel accounts need to be provisioned and managed from a central system.

The billing system handles the payment.

The automation system handles the infrastructure.

Each component has a clear responsibility.

Logging Is Extremely Important

One of the biggest lessons I learned from automation is this:

An API call failing silently is worse than an API call failing loudly.

Imagine a customer pays for hosting.

Your application tries to create the account.

The API fails.

But your application doesn't store the error.

Now the billing system says:

Order: Active

while the server says:

Account: Does not exist

That's a serious operational problem.

Every important API operation should therefore be logged.

For example:

2026-08-25 10:32:10
Action: create_account
Domain: example.com
Username: customer123
Status: failed
HTTP Code: 403

You should also store useful information such as:

Request ID
Action
Server
Account ID
API response status
Error message
Timestamp
Retry count

But don't log sensitive information such as API tokens or customer passwords.

Handling API Errors

Not every failed API request means the same thing.

For example:

401 / 403

could indicate an authentication or permission problem.

A timeout could mean:

Network problem

A validation error could mean:

Invalid domain
Invalid username
Invalid package

A server error could mean:

Temporary infrastructure problem

Therefore, I prefer to classify errors.

For example:

if ($response['status'] === 403) {
    // Authentication or permission issue
}

if ($response['status'] >= 500) {
    // Server-side failure
}

if ($response['status'] >= 400) {
    // Client/request error
}

The application can then decide whether to retry the request or mark the operation as failed.

Retry Logic

Retries are useful, but blindly retrying every failed request is a bad idea.

For example, if an account creation request times out, you don't necessarily know whether the server created the account or not.

If you immediately retry, you could potentially create a duplicate operation or get a confusing error.

A safer strategy is:

API Request
    |
    v
Timeout
    |
    v
Check Account Status
    |
    +---- Account Exists ---> Mark Success
    |
    +---- Account Missing --> Retry

This is one of the reasons idempotency and state verification are important in automation.

Security Considerations

Automation gives you power.

That also means a compromised automation system can cause serious damage.

I follow several basic security principles.

1. Protect API tokens

Never expose tokens to the frontend.

2. Use HTTPS

API communication should always use encrypted connections.

3. Use least privilege

Don't give an application more permissions than necessary.

4. Validate input

Never send raw customer input directly into server operations.

Validate:

Domain names
Usernames
Package names
Account IDs
Database names

5. Restrict internal endpoints

If your application has an endpoint like:

/api/create-account

don't leave it publicly accessible without authentication and authorization.

6. Log operations

You need to know who triggered an infrastructure change.

Multi-Server Automation

Once you start managing multiple servers, the architecture becomes even more interesting.

Instead of hardcoding one server:

$server = "server1.example.com";

you can maintain a server inventory.

For example:

Server 1
- Location: India
- Provider: XYZ
- Status: Active

Server 2
- Location: Singapore
- Provider: XYZ
- Status: Active

Server 3
- Location: Germany
- Provider: ABC
- Status: Active

Your automation layer can then decide which server should receive a new hosting account.

For example:

New Order
   |
   v
Find Available Server
   |
   v
Check Resources
   |
   v
Provision Account

This is much closer to a real hosting platform architecture than simply calling cPanel APIs. For example, a provider offering VPS hosting can use the same infrastructure-management principles while keeping server-level automation separate from customer-facing billing logic.

Adding Resource Monitoring

Another useful feature is resource monitoring.

You can periodically retrieve information such as:

Disk usage
Bandwidth usage
Account count
Server load
Available resources
Service status

Then display the information in your own admin panel.

Instead of logging into multiple servers, an administrator can see everything in one place.

For example:

Server Dashboard

Server 1
CPU:       42%
RAM:       61%
Disk:      48%
Accounts:  312

Server 2
CPU:       27%
RAM:       52%
Disk:      39%
Accounts:  198

This is where API automation starts becoming genuinely useful. Instead of checking every server manually, the same approach can support different hosting environments, including managed cloud hosting, from one administration layer.

You're no longer just automating one button.

You're building an infrastructure management layer.

Building a Central Automation Layer

Eventually, I found that the best approach is to keep cPanel-specific logic in one place.

The rest of the application should communicate with something like:

HostingService
      |
      +-- createAccount()
      +-- suspendAccount()
      +-- unsuspendAccount()
      +-- changePackage()
      +-- terminateAccount()
      +-- getUsage()
      +-- createDatabase()

Internally, HostingService communicates with cPanel.

This architecture makes it easier to change the underlying infrastructure later.

For example, today you might use cPanel.

Tomorrow you might add another control panel or a custom server management system.

The billing application shouldn't need to change completely.

What I Would Improve in a Production System

If I were building the system again from scratch, I would focus heavily on reliability.

The API client should have:

Connection timeout
Request timeout
Structured errors
Logging
Retry handling
Request IDs
Authentication management
Rate limiting
Permission checks
Server health checks

I would also add a job queue.

Instead of doing everything during a customer's HTTP request:

Customer clicks Upgrade
        |
        v
Wait for API
        |
        v
Wait for server
        |
        v
Wait for backup
        |
        v
Return response

I would use:

Customer clicks Upgrade
        |
        v
Create Job
        |
        v
Queue
        |
        v
Worker
        |
        v
cPanel API

This is much more reliable for long-running operations.

The Biggest Lesson

The biggest lesson from automating hosting management is that APIs aren't the difficult part.

Calling an API is relatively easy.

The difficult part is designing what happens when something goes wrong.

What happens if the API times out?

What happens if the account was created but your application didn't receive the response?

What happens if payment succeeds but provisioning fails?

What happens if the customer upgrades twice?

What happens if the server becomes unavailable?

What happens if an administrator manually changes something in cPanel?

These are the problems that matter in production.

A good automation system isn't just:

API Request → Success

It is:

Request
   ↓
Validate
   ↓
Authenticate
   ↓
Execute
   ↓
Verify
   ↓
Log
   ↓
Retry / Recover if required
   ↓
Update Application State

That's the difference between a script and a production system.

Final Thoughts

Automating cPanel with APIs completely changes how hosting infrastructure can be managed.

Instead of manually performing repetitive operations, your application can handle provisioning, suspension, upgrades, monitoring, backups, and other workflows programmatically.

The basic technology isn't complicated.

PHP can communicate with cPanel APIs using HTTP requests and API tokens.

The real engineering challenge is building a reliable layer around those APIs.

If you're building a hosting platform, reseller hosting system, billing panel, or internal server management tool, I strongly recommend starting with a clean API abstraction instead of scattering cPanel API calls throughout your application. This is also useful for specialized products such as WordPress hosting, where provisioning, backups, SSL, and account management can be connected to the same automation layer.

Start small:

API Client
    ↓
Create Account
    ↓
Suspend Account
    ↓
Unsuspend Account
    ↓
Change Package

Then add:

Logging
Monitoring
Retries
Queues
Multi-server support

Once those pieces are in place, you can build much more advanced automation on top of the same foundation.

And that's the real advantage of API-driven infrastructure:

You stop managing servers manually and start managing infrastructure through software.

What are you automating with cPanel APIs?

If you're building something similar, I'd be interested to know what you're automating—hosting provisioning, WHMCS integration, backups, server monitoring, or something else.

Share your approach in the comments.

Why Puffx Host Deserves a Look in 2026

Nitin Mehta — Tue, 04 Aug 2026 04:50:55 +0000

When it comes to web hosting, most "best of" lists are dominated by the same big names — Hostinger, SiteGround, Bluehost, DigitalOcean. And for good reason, they're proven. But there's a growing list of smaller, India-focused hosting providers worth keeping an eye on, and one that's been popping up lately is Puffx Host.

Here's an honest look at what they offer, based on what's publicly available — not a paid promotion.

What Puffx Host Offers

Puffx Host is an India-based hosting provider offering SSD web hosting, cloud hosting, VPS hosting, and dedicated servers, positioned around 99.9% uptime. Their plan lineup covers the usual bases:

Shared hosting (Mini/SMM Panel/Indian Cloud hosting tiers)
WordPress hosting
Reseller & Master Reseller hosting
VPS / RDP
A free hosting tier with limited bandwidth

A few things stand out on their spec sheet:

NVMe SSD storage on most plans
Free SSL certificates across plans
cPanel control panel (familiar territory if you've used other hosts)
Daily backups and what they describe as enhanced security
Free CDN (branded as "Supersonic CDN")
24/7 live chat and phone support

Pricing & Guarantees

Being India-focused, pricing is positioned as budget-friendly compared to international hosts — useful if you're building for an Indian audience and want servers physically closer to your users for lower latency. They also advertise a 7-day money-back guarantee and free website migration when switching from another host.

The Honest Caveat

This is where I'd push back on any post that just lists a host's marketing points and calls it a day: check current reviews before committing. Puffx Host's reviews online are mixed — some users report a genuinely good experience with responsive support, while others have raised complaints about billing or service issues. That's not unusual for a smaller/newer host (it happens with bigger names too), but it means you should:

Read recent reviews (not just the ones linked on their own site)
Start with a lower-tier or monthly plan before committing to a yearly one
Test their support responsiveness before you have a production site depending on it
Confirm uptime claims against an independent monitor once you're hosted with them

Who Might Want to Try It

Puffx Host could make sense if you're:

Building a project primarily for an Indian audience and want local server latency
Looking for a budget alternative to test before scaling up
OK being an early adopter with a newer provider, in exchange for potentially lower pricing

If you need a long track record, enterprise SLAs, or you're hosting something business-critical from day one, sticking with an established provider (Hostinger, DigitalOcean, Cloudways, etc.) is still the safer bet.

Final Thoughts

Puffx Host isn't going to dethrone the big names overnight, and it shouldn't be ranked above them without a real track record to back that up. But as a budget, India-based option worth testing for smaller or personal projects, it's a reasonable one to have on your radar in 2026 — just go in with eyes open and do your own due diligence first.

Have you used Puffx Host or a similar regional hosting provider? Share your experience in the comments 👇

Cheap Hosting vs Reliable Hosting: What I Learned Running My Own Company Tags: webdev, hosting, devops, startup

Nitin Mehta — Sat, 01 Aug 2026 05:58:46 +0000

When I started out, I thought hosting was hosting — buy the cheapest plan, point your domain, done. A few crashed sites, angry clients, and 3 AM support tickets later, I learned that's not even close to true.

The Cheap Hosting Trap

Every beginner developer goes through this phase. You find a plan for ₹99/month, it looks great on paper — "unlimited" storage, "unlimited" bandwidth, free SSL. But then reality hits:

Shared servers packed with hundreds of other sites, so your site slows down during someone else's traffic spike
Support tickets that take 24-48 hours to even get a first reply
No real uptime monitoring — you find out your site was down only when a client calls you
"Unlimited" resources that get throttled the moment you actually use them

A Real Example

One of my early clients ran a small e-commerce store. Nothing huge — maybe 200-300 visitors a day. Their host was one of those "unlimited everything for ₹99" plans. The week before Diwali, they ran a sale post on Instagram. Traffic spiked to about 2,000 visitors in a few hours.

The site went down. Completely. Not slow — down. I raised a support ticket immediately. First reply came 14 hours later, by which time the sale window had basically closed. The client lost real revenue over something that should have been a routine traffic spike, not an outage.

That single incident taught me more about hosting than any blog post ever did: the price tag tells you nothing about what happens under load.

How to Actually Test a Host Before Buying

Don't trust the sales page. Here's what I check now, and what any developer can check in a few minutes:

Ping and response time — run a simple check from your terminal:

   curl -o /dev/null -s -w "Connect: %{time_connect}s Total: %{time_total}s\n" https://example.com

Anything consistently over 500ms for a basic page load is a red flag.

Uptime history — use a free tool like UptimeRobot or StatusCake to monitor a host's demo/status page for a week before committing.
Support response time — open a pre-sales chat and ask a technical question (e.g. "what CPU/RAM isolation do you provide on shared plans?"). If they can't answer clearly or take hours to reply, that's your support experience after you pay too.
Resource isolation — ask directly whether shared hosting plans use CloudLinux or similar CPU/RAM isolation. Hosts that don't often oversell the same physical server to too many accounts.
Backup policy — confirm backups are automated and how far back they go. "We have backups" without specifics usually means manual, occasional, or none.

What Actually Matters in Hosting

After running dozens of client sites and eventually building my own infrastructure, here's the short list I now judge every host against:

Real uptime guarantees — not just marketing copy, actual SLA numbers
Server response time — test it yourself, don't trust the sales page
Support that responds fast — live chat with real humans, not just ticket queues
Resource isolation — so one noisy neighbor site doesn't kill your performance
Automated backups — because things will break eventually

Why I Ended Up Building My Own Solution

The more clients I onboarded, the more I realized I was troubleshooting other companies' infrastructure problems instead of building. So I started automating server provisioning, WHMCS + API integrations, and monitoring — basically solving my own pain points one at a time.

That eventually became Puffx Host — built specifically around the things I wished my old hosts had: fast support, honest resource limits, and infrastructure I actually understand end-to-end because I built the automation myself.

Quick FAQ

Is cheap hosting always bad?
No — for a personal blog or portfolio with low traffic, a cheap plan is often fine. The problem is using it for anything client-facing or revenue-generating without testing it first.

What's the single biggest red flag?
Slow or vague answers to technical pre-sales questions. If they can't answer clearly before you've paid, support won't improve after.

Should I always go with the most expensive plan?
Not necessarily. Price isn't the signal — isolation, uptime history, and support quality are. Some mid-priced hosts outperform "premium" ones on all three.

Takeaway

If you're a developer choosing hosting for a client or your own project, don't just compare price tags. Test support response time, ask about real server specs, and check what happens under a traffic spike — because eventually, there will be one.

What's your worst hosting horror story? Drop it in the comments 👇

I Tried Building a Money Earning App — Here’s What Actually Happened (No BS)

Nitin Mehta — Sun, 26 Apr 2026 05:09:44 +0000

💸 I Tried Building a Money Earning App — Here’s What Actually Happened

Let’s cut the fantasy.

“Money earning apps” look simple from the outside:

Complete tasks
Earn money
Withdraw instantly

So I decided to build one myself and see how it actually works behind the scenes.

🧠 The Original Plan (Sounds Perfect on Paper)

The model was straightforward:

User signs up
Completes tasks (clicks, ads, referrals)
Earns small rewards
Requests withdrawal

Revenue source:
👉 Ads + affiliate links

On paper, this looks like a self-running system.

In reality, it breaks very fast.

⚙️ What I Actually Built

I didn’t just make a UI. I built a working system:

Core Modules:

Authentication (email + OTP)
Task engine (daily tasks, cooldown system)
Wallet system (credit/debit tracking)
Withdrawal system (manual + auto)
Admin panel (user control + fraud detection basics)

Tech Stack:

Backend: PHP (custom APIs)
Database: MySQL
Frontend: Basic web dashboard
Hosting: Shared server (cheap but enough to test)

Everything worked.

Users could sign up, complete tasks, and see earnings.

And that’s exactly when problems started.

⚠️ Problem #1 — Bots & Exploits (Worse Than You Think)

Within 48–72 hours:

Same IP → multiple accounts
Automated scripts hitting APIs
Fake task completions

People weren’t using the app.

They were trying to break it.

What I Tried:

Rate limiting
IP tracking
Basic captcha

Reality:

👉 If money is involved, people WILL exploit your system.

⚠️ Problem #2 — The Math Doesn’t Work

This is the biggest lie in earning apps.

Let’s break it:

Ad revenue per user ≈ ₹2–₹5
User expectation ≈ ₹20–₹50

Now multiply:

100 users → you earn maybe ₹300
But payout demand → ₹2000+

👉 You are running at a loss from day 1.

Unless:

You scam users
Or you heavily restrict withdrawals

There’s no middle ground.

⚠️ Problem #3 — Trust Is Everything (And You Have None)

Users don’t trust new platforms.

Questions I got:

“Payment proof?”
“Is this legit?”
“When will I get paid?”

Even if your system is real…

👉 Without reputation, users assume it's fake.

⚠️ Problem #4 — Withdrawals Are a Nightmare

This part is underrated.

Handling real money means:

Payment gateway fees
Fraud checks
Chargebacks
Manual verification

Even small payouts become complicated.

One mistake = loss + angry users.

⚠️ Problem #5 — Users Don’t Stay

Even after all that:

Users come for money
Not for product

So:

👉 No loyalty

👉 No retention

👉 No real growth

They leave the moment earnings slow down.

💥 The Real Truth (No Sugarcoating)

This is NOT a coding problem.

It’s a broken business model.

Most “earning apps” survive because:

They delay payments
They cap withdrawals
Or they are straight-up scams

🧠 What I Learned (Actual Lessons)

Code is the easiest part
Users exploit everything
Monetization matters more than features
Trust takes time, not UI

🚀 If I Had to Start Again

I would NOT build an earning app.

Instead:

Build SaaS tools
Solve real problems
Charge directly (simple model)

Because:

👉 Direct value > fake earning loop

🔥 Final Advice (For Developers)

If you're thinking:

“I’ll build an earning app and make money”

Stop.

Ask yourself:

Where is the real revenue coming from?
Why would users trust you?
How will you prevent abuse?

If you don’t have answers…

👉 Don’t build it.

📌 Conclusion

I didn’t fail because I couldn’t code it.

I failed because I understood how the system actually works.

And honestly…

That lesson is worth more than the app itself.

How I Built a Web Hosting Business at 16 (With Automation & Zero Team)

Nitin Mehta — Sun, 19 Apr 2026 08:21:21 +0000

🚀 How I Built a Web Hosting Business at 16 (With Automation & Zero Team)

Most people think starting a hosting business needs a team, big investment, or advanced infrastructure.

I started with none of that.

Here’s exactly how I built my hosting platform — step by step.

🎮 Step 1: Starting with Zero Income

I didn’t start as a developer.

I started as a gaming content creator (BGMI on YouTube).

No income. No growth.

But that phase taught me one thing — how the internet ecosystem works.

💰 Step 2: Discovering SMM Panels

I entered the SMM panel space (selling followers, likes, views).

At first, I was just a reseller.

But I noticed something important:

The real money is in owning the system, not reselling it.

⚙️ Step 3: Learning the Backend

I started learning:

How domains & hosting work
How APIs connect services
Payment gateway integrations
Basic server management

This is where things changed.

🔄 Step 4: Building Automation

Instead of doing things manually, I focused on automation:

API-based order processing
Auto account setup
Billing via WHMCS
Server control via cPanel/WHM

Result:

Less manual work, more scalability.

🌐 Step 5: Launching Puffx Host

I launched my platform (initially Puffx Live Host).

Then improved it into Puffx Host.

Services I focused on:

Shared hosting
Reseller hosting
SMM panel setup
Automation tools

🧠 What I Learned

Don’t depend on manual work → automate everything
Learn systems, not just tools
Start small, scale later
Real skill = solving problems, not watching tutorials

⚡ Current Focus

Now I’m working on:

Better server performance
Scalable infrastructure
Advanced automation systems

👋 Final Thoughts

You don’t need a perfect plan.

You need to start, learn, and build systems that scale.

If you're building something similar or working on hosting/automation — let’s connect.

DEV Community: Nitin Mehta

I Built a Self-Hosted WhatsApp Gateway Using Node.js, Docker and PostgreSQL

Building Puffx WhatsApp Gateway: A Self-Hosted WhatsApp Messaging API with Node.js, Docker and PostgreSQL

Introduction

1. What Is Puffx WhatsApp Gateway?

Main Features

2. Technology Stack

Why Docker?

Why PostgreSQL?

3. Understanding the Architecture

4. Installing the Project with Docker

Requirements

Step 1: Clone the Repository

Step 2: Configure Environment Variables

Step 3: Start Docker Compose

Step 4: Open the Dashboard

Step 5: Check Container Status

5. Connecting a WhatsApp Account

6. Generating an API Key

7. Sending Your First WhatsApp Message Through the REST API

API Endpoint

Authentication

Request Body

Complete cURL Example

8. Integrating with Other Programming Languages

9. Can It Run on a VPS?

10. Security Considerations

11. Current Beta Status and Limitations

12. Why I Started This Project

13. Open Source and Community Feedback

Conclusion

Disclaimer

PHP2Shell: Two Critical PHP Security Vulnerabilities Every Developer Should Know About

PHP2Shell Explained: Critical PHP RCE Vulnerabilities, Affected Versions, and How to Secure Your Server

1. What Is PHP2Shell?

2. Why Is Remote Code Execution So Dangerous?

3. Technical Overview: How the Two Vulnerabilities Differ

CVE-2026-109618: Memory Corruption During Out-of-Memory Handling

CVE-2026-109619: Stale Internal State

4. Which PHP Versions Are Affected?

What about PHP 8.1, 8.0, and 7.4?

5. How to Check Your Website's PHP Version

Method A: Using SSH

Method B: Using cPanel

6. How to Patch PHP2Shell Properly

Step 1: Inventory your PHP installations

Step 2: Prioritize internet-facing systems

Step 3: Install the correct security update

Step 4: Restart the relevant services

Step 5: Verify the running runtime

Step 6: Test the application

7. Are WordPress Websites Affected?

8. What If You Cannot Update Immediately?

9. How to Investigate a Potential Compromise

10. What Hosting Providers Should Do

11. Developer Checklist

Conclusion

Official References

About Puffx Host

php #security #webdev #devops

Best Web Hosting in 2026: Top 20 Hosting Providers Compared

Best Web Hosting in 2026: Top 20 Hosting Providers Compared

Table of Contents

1. What Makes a Good Web Hosting Provider?

Performance and loading speed

Uptime and reliability

Security

Pricing and renewal costs

Customer support

2. Top 20 Web Hosting Providers in 2026

1. Puffx Host — An Option for Indian Customers

2. Hostinger — Beginner-Friendly Hosting

3. Bluehost — WordPress Websites

4. SiteGround — Managed Website Hosting

5. HostGator — General-Purpose Hosting

6. DreamHost — Websites and WordPress

7. A2 Hosting / Hosting.com — Performance-Focused Hosting

8. InMotion Hosting — Business and Reseller Hosting

9. GreenGeeks — Environmentally Focused Hosting

10. Kinsta — Premium Managed WordPress