DEV Community: Nitin Mehta

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.