DEV Community: Om Dongaonkar

What Happens When You Move From Shared Hosting to a VPS

Om Dongaonkar — Tue, 10 Mar 2026 11:06:23 +0000

Micrologs v1 was deliberately constrained. PHP + MySQL, no Redis, no background workers, no VPS required. The pitch was: drop one file on your $2/month shared host and start tracking. That worked. v1.3.1 is the stable shared hosting release and it handles ~10,000 pageviews/day without complaint.

But somewhere around v1.3.1, I started thinking about what happened when you removed those constraints.

Not "rewrite in Go" or "switch to Postgres." Same PHP. Same MySQL. Just a VPS — which means persistent processes, background workers, and access to a fast in-memory store like Valkey.

The ceiling went from ~10,000 pageviews/day to ~500,000 on a single node. With proper load balancing and node management, that number climbs to ~2.4M. Here's what actually changed and why.

The real constraint on shared hosting isn't the hardware

On shared hosting, PHP starts fresh on every request, does its work, and dies. No state between requests. No background processes. No way to keep anything alive between calls.

This means every single thing that needs to happen for a pageview — auth, geolocation, user agent parsing, database writes — has to happen synchronously, inside that one request, while the user's browser waits for a response.

On a quiet site, that's fine. Under real load, it becomes the ceiling. PHP-FPM workers pile up waiting on database queries. The connection pool saturates. Everything slows down together.

The problem isn't that shared hosting is slow. It's that the synchronous-everything model has nowhere to go. You can't offload work anywhere, because there's nowhere to offload it to.

On a VPS, that changes.

What a VPS actually unlocks

Two things specifically:

Persistent processes. PHP-FPM workers are long-lived on a VPS. A cached value in process memory stays cached. A Valkey connection stays open. A background worker keeps running. You stop paying the cold-start cost on every single request.

Background work. You can run Supervisor. You can keep worker processes alive. You can have things happening in the background that have nothing to do with the current HTTP request. This is the big one.

Micrologs v2 uses both.

The shift: stop doing everything in the request cycle

In v1, a single pageview triggered the full stack synchronously — geolocation, user agent parsing, session resolution, database writes — all of it blocking, all of it happening while the browser waited.

In v2, the tracking endpoint does almost nothing. It validates auth, hashes the IP, and pushes the raw payload to a Valkey queue. That's it. Response goes back to the browser in ~2–5ms.

The actual work — GeoIP lookup, UA parsing, all the database writes — happens in a background worker that pulls from the queue and processes jobs completely off the HTTP request cycle.

The data that ends up in the database is identical to v1. The enrichment still happens. It just happens after the response, not before it.

This one shift is responsible for most of the throughput gain. A PHP-FPM worker that responds in 2ms can handle ~30,000 requests/minute. One that responds in 150ms handles ~400. That gap is the ceiling difference between v1 and v2.

Caching on the read side

The queue handles writes. Valkey also handles reads.

Analytics queries are expensive — they touch a lot of rows. In v1, every analytics request hit MySQL directly. If you're polling a dashboard every 30 seconds, you're running that query every 30 seconds.

In v2, the first request hits MySQL and the result is cached in Valkey with a TTL. Every request within that window returns the cached result at ~2ms. Workers invalidate the cache when new data is written. Polling dashboards become nearly free.

Schema cleanup

This one doesn't make headlines but it compounds over time.

Redundant indexes, dead indexes from old query paths, composite indexes that could be consolidated — v2.1.0 was a cleanup pass on all of it. The DB sees less write amplification per INSERT and the indexes stay leaner as the dataset grows. On a small dataset these gains are invisible. On a table with millions of rows under sustained write load, they matter.

What the numbers look like

Stress test: 100 virtual users, 60 seconds, Docker on WSL2.

Metric	Before (v2.1.0)	After (v2.2.0)
Requests/minute	~1,300	~16,000
p95 latency	~6,000ms	~400ms
Error rate	high	~2% (WSL2 TCP noise)

The ~2% error rate is from WSL2's virtualisation layer, not the application. On a real Linux VPS, p99 < 10ms is expected.

The ceiling, explained

v1.3.1 (shared hosting): ~10,000 pageviews/day. Synchronous everything. Runs on $2/month.

v2.2.0 (single VPS node): ~500,000 pageviews/day. Async queue, background workers, analytics cache.

v2.2.0 (with load balancing + multiple nodes): Theoretically unbounded. The async architecture is horizontally scalable by design — stateless tracking endpoint, workers pulling from a shared queue. How far it scales depends entirely on how much infrastructure you throw at it. Adding nodes doesn't require redesigning anything.

There's still a lot left to do

Honest caveat: v2 is not a fully optimized system. It's a meaningfully better architecture than v1, and the numbers show that. But there are optimizations I haven't touched yet — better worker concurrency tuning, smarter cache invalidation, connection pooling, more granular queue prioritization.

I'll get to them as I learn more. That's the honest state of it. Every version of Micrologs has been the same loop: build it, ship it, review it under real conditions, find what breaks, fix it. v2 is no different. The 500k ceiling is real today. What it looks like in v3 depends on what I learn between now and then.

The project

Micrologs is MIT licensed. v1.3.1 is the stable shared hosting release. v2.2.0 is the current stable VPS release.

GitHub: github.com/OmDongaonkar03/Micrologs

Your portfolio site is probably broken in ways you haven't checked

Om Dongaonkar — Wed, 04 Mar 2026 21:20:51 +0000

Most developers spend weeks building their portfolio. The design, the animations, the perfect copy. Then they deploy it and never look at it again.

I did the same thing. Until this week, when I actually checked mine properly for the first time.

Here's what I found - and why your site probably has the same issues.

The Audit

I ran two checks. One for performance, one for security.

Performance: Chrome DevTools → Network tab, throttled to Fast 3G.
Security: securityheaders.com - paste your URL, get a grade.

My results:

Load time: 4.27s
Data transferred: 227 kB
Security grade: D

Not catastrophic. But not good for a site whose entire purpose is to make a first impression on a hiring manager or potential client.

The Performance Problem

The culprit was immediately obvious in the Network tab: 16 separate PNG requests just for favicons and icons.

Every request has overhead - DNS lookup, TCP handshake, HTTP round trip. 16 small image requests is worse than 1 slightly larger one.

The fix: replace them with inline SVGs directly in the component. No network requests at all.

// Before - 16 separate image requests
<img src="/icons/github.png" />
<img src="/icons/linkedin.png" />
// ... 14 more

// After - zero network requests
<svg viewBox="0 0 24 24" ...>
  <path d="..." />
</svg>

The second fix: lazy load everything below the fold. React makes this trivial.

import { lazy, Suspense } from "react";

const Projects = lazy(() => import("./sections/Projects"));
const Contact = lazy(() => import("./sections/Contact"));

// In your JSX
<Suspense fallback={null}>
  <Projects />
  <Contact />
</Suspense>

The browser now only loads what the user can actually see. Everything else loads as they scroll.

Result: 4.27s → 2.00s. 227 kB → 17.7 kB transferred.

Same site. Same content. Half the load time, 92% less data.

The Security Problem

A D grade on securityheaders.com means your site is missing HTTP security headers. These are response headers your server sends that tell the browser how to behave - what it can load, where it can connect, whether it can be embedded in an iframe.

Missing them doesn't break your site. But it means:

Your site can be embedded in an iframe on another domain (clickjacking)
Browsers won't enforce HTTPS strictly
No protection against content injection

The fix for a Cloudflare Pages site is a single _headers file in your /public folder:

/*
  Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  X-Frame-Options: SAMEORIGIN
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
  Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https:; frame-ancestors 'none';

One file. No backend changes. No server config. Cloudflare picks it up on the next deploy.

Result: D → A on securityheaders.com.

What I Built On Top

After fixing the portfolio, I built a blog - this one, at blogs.omdongaonkar.in - as a subdomain of the same domain. Vite + React, posts written in Markdown, auto-deployed to Cloudflare Pages on every push.

Total additional cost: zero. The domain was already there. Cloudflare Pages is free. A subdomain is just a DNS record.

The same _headers file approach applies here too. Same security setup, same caching rules, consistent across both.

The Actual Takeaway

None of this was hard. The performance fixes took just 10 mins and security headers just took 20 minutes. The blog took a day.

The reason most portfolio sites have these issues isn't lack of skill - it's that nobody checks. You build the thing, it looks good in the browser, you ship it and move on.

Run securityheaders.com on your site right now. Open DevTools on a throttled connection. See what actually loads.

You'll probably find the same things I did.

I Reviewed My Own Code Like I Was Trying to Break It

Om Dongaonkar — Sun, 01 Mar 2026 18:08:40 +0000

Last week I built and shipped Micrologs - a self-hostable analytics and error tracking engine that runs on shared hosting. PHP + MySQL. No Redis, no VPS, no Docker. That post covers how it's built and why.

This post is about what happened the day after I shipped it.

I did a full security and performance review on my own code. Treated it like I was a senior engineer seeing it for the first time, trying to find every way it could fail under real traffic.

I found 5 real issues. None exotic. All fixable. All the kind of thing that doesn't hurt at 100 visits/day and quietly breaks at 10,000.

Here's exactly what I found and how I fixed each one.

Issue 1 - Blind trust of X-Forwarded-For

The problem:

function getClientIp()
{
    if (!empty($_SERVER["HTTP_X_FORWARDED_FOR"])) {
        $ips = explode(",", $_SERVER["HTTP_X_FORWARDED_FOR"]);
        return trim($ips[0]); // ← anyone can spoof this
    }
    return $_SERVER["REMOTE_ADDR"] ?? "";
}

X-Forwarded-For is a header that proxies add to tell your app the real client IP. The problem: it's just a header. Any client can send their own:

X-Forwarded-For: 127.0.0.1

Now your rate limiter thinks they're localhost. They can make unlimited requests. Your GeoIP lookup gets a fake IP. Your IP hash is poisoned. The fix costs an attacker zero effort.

The fix:

REMOTE_ADDR is set by the TCP connection itself - it cannot be spoofed. X-Forwarded-For can. So only trust it when REMOTE_ADDR is a proxy you control:

function getClientIp()
{
    $remoteAddr = $_SERVER["REMOTE_ADDR"] ?? "";

    $trustedProxies = [];
    if (defined("TRUSTED_PROXIES") && TRUSTED_PROXIES !== "") {
        $trustedProxies = array_map("trim", explode(",", TRUSTED_PROXIES));
    }

    if (!empty($trustedProxies) && in_array($remoteAddr, $trustedProxies, true)) {
        if (!empty($_SERVER["HTTP_X_FORWARDED_FOR"])) {
            $ips = array_map("trim", explode(",", $_SERVER["HTTP_X_FORWARDED_FOR"]));
            $clientIp = $ips[0];
            if (filter_var($clientIp, FILTER_VALIDATE_IP)) {
                return $clientIp;
            }
        }
    }

    return $remoteAddr;
}

On shared hosting with no proxy in front - set TRUSTED_PROXIES to empty and XFF is ignored entirely. On a VPS with Nginx in front of PHP-FPM - set it to 127.0.0.1 and it works correctly.

Issue 2 - No payload size cap

The problem:

$input = json_decode(file_get_contents("php://input"), true);

This was in every single endpoint. file_get_contents("php://input") reads the entire request body with no limit whatsoever. Send a 500MB POST - the server loads 500MB into memory. Do it 10 times concurrently - the server is out of memory and dead. This is a trivial DoS attack that requires zero skill.

The fix:

A readJsonBody() helper that hard-caps at 64KB:

function readJsonBody(int $maxBytes = 65536): ?array
{
    $raw = file_get_contents("php://input", false, null, 0, $maxBytes + 1);

    if ($raw === false || $raw === "") {
        return null;
    }

    if (strlen($raw) > $maxBytes) {
        sendResponse(false, "Payload too large", null, 413);
    }

    $decoded = json_decode($raw, true);
    return is_array($decoded) ? $decoded : null;
}

64KB is enormous for any legitimate tracking payload - a pageview beacon is maybe 500 bytes. This cap only ever affects attackers. Every endpoint now calls readJsonBody() instead of the raw file_get_contents.

Issue 3 - Unbounded context field

The problem:

Error and audit endpoints accepted a context field - arbitrary JSON the caller can attach to any event:

$context = isset($input["context"]) && is_array($input["context"])
    ? json_encode($input["context"])
    : null;

A deeply nested 10MB JSON object sent as context would be encoded and pushed straight to the DB. Even with the payload cap from issue 2 in place, 64KB of deeply nested JSON can consume significantly more memory during json_encode than its raw byte size suggests.

The fix:

Encode first, then check:

function encodeContext($raw, int $maxBytes = 8192): ?string
{
    if (!isset($raw) || !is_array($raw)) {
        return null;
    }

    $encoded = json_encode($raw, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);

    if ($encoded === false || strlen($encoded) > $maxBytes) {
        return null; // drop silently - the event still records, context doesn't
    }

    return $encoded;
}

8KB is plenty for any real error context. Oversized context is dropped silently - the error or audit event still gets recorded. You lose the context blob, not the event.

Issue 4 - 15 database queries per pageview

The problem:

This was the performance bottleneck. Every single pageview fired up to 15 sequential round-trips to MySQL:

SELECT visitor → maybe INSERT visitor → UPDATE visitor last_seen
SELECT session → maybe INSERT session → UPDATE session last_activity
SELECT dedup check
SELECT location → maybe INSERT location
SELECT device   → maybe INSERT device
SELECT bounce count → maybe UPDATE bounce flag
INSERT pageview

On shared hosting with 15–25 max DB connections, under 50 concurrent users these pile up and the connection pool saturates.

The fix - INSERT ... ON DUPLICATE KEY UPDATE:

This single MySQL statement does: "insert this row, but if a row with this unique key already exists, update it instead." One query instead of two, atomically.

Visitor upsert:

INSERT INTO visitors (project_id, visitor_hash, fingerprint_hash)
VALUES (?, ?, ?)
ON DUPLICATE KEY UPDATE
    fingerprint_hash = IF(
        fingerprint_hash = '' AND VALUES(fingerprint_hash) != '',
        VALUES(fingerprint_hash),
        fingerprint_hash
    ),
    last_seen = NOW()

Session upsert:

INSERT INTO sessions (project_id, visitor_id, session_token)
VALUES (?, ?, ?)
ON DUPLICATE KEY UPDATE
    last_activity = NOW()

Bounce flag - replaced a separate COUNT(*) query + conditional UPDATE with a single conditional UPDATE using an inline subquery:

UPDATE sessions
SET is_bounced = 0
WHERE id = ?
  AND is_bounced = 1
  AND (SELECT COUNT(*) FROM pageviews WHERE session_id = ?) > 1

Result: 15 queries → 6–8 in the typical path for a returning visitor. The DB connection pool stays healthy under load.

Issue 5 - GeoIP file opened on every request

The problem:

$reader = new \MaxMind\Db\Reader($dbPath);
$record = $reader->get($ip);
$reader->close();

Every tracking request opened the .mmdb file, read it, and closed it. Opening a file means a filesystem call - finding it on disk, loading it into memory, initialising the reader object. On a busy endpoint, this was 20–80ms of overhead per request, every request.

The fix - PHP static variables:

A static variable inside a function is initialised once and persists for the lifetime of that PHP-FPM worker process. Every subsequent call reuses it - no re-initialisation, no file open.

static $reader = null;
if ($reader === null) {
    $reader = new \MaxMind\Db\Reader($dbPath);
}
$record = $reader->get($ip);
// no close() - PHP cleans it up at process shutdown

First request: opens the file. Every request after that within the same worker process: reuses the open reader. Free performance, zero risk.

Two operational fixes

Log rotation - file_put_contents($logPath, $line, FILE_APPEND) appended forever. One busy month and you have a 2GB log file. Shared hosting has disk quotas. A silent disk full means your site stops working with no explanation.

Fixed with shift rotation - before writing, check file size. If over 10MB, shift all existing files down (.1→.2 ... up to .5, oldest deleted) and start fresh. Max 60MB on disk, last 50MB of history always preserved. Pure PHP, no cron.

Request ID in logs - before this fix, logs under load looked like:

[14:22:01] [ERROR] [pageview.php] DB insert failed
[14:22:01] [ERROR] [pageview.php] DB insert failed
[14:22:01] [ERROR] [pageview.php] DB insert failed

3 errors at the same second. Is this 1 request that failed 3 times, or 3 different requests that each failed once? You can't tell.

Fixed by generating a unique 8-character ID per HTTP request at the top of functions.php:

$GLOBALS["request_id"] = substr(bin2hex(random_bytes(4)), 0, 8);

writeLog() includes it automatically. Now:

[14:22:01] [ERROR] [a3f9c12b] [pageview.php] DB insert failed
[14:22:01] [ERROR] [a3f9c12b] [pageview.php] DB insert failed
[14:22:01] [INFO]  [f91c3d77] [pageview.php] pageview recorded

Same ID = same request. grep "a3f9c12b" micrologs.log shows the complete story of that one request from start to finish.

What this changed

After all fixes, Micrologs handles ~10,000 pageviews/day on a standard shared host. No Redis, no queue, no VPS required.

The five issues above aren't exotic bugs. They're the standard gap between "works in development" and "survives real traffic." None of them showed up in testing. All of them would have shown up under load.

The lesson I keep re-learning: shipping v1 is step one. Reviewing it like you're trying to break it is step two. Most developers skip step two.

What shipped after

This post covers v1.1.0. Since then:

v1.2.0 - Three new analytics endpoints using existing data, no schema changes: session duration and pages per session, new vs returning visitors, and error trends over time with daily breakdowns.

v1.3.0 - Complete API coverage. Full project management (list, toggle, enable/disable, rotate keys, delete). Link edit and detail endpoints. Error group status updates — individually or in bulk, with a new investigating status for the full open → investigating → resolved / ignored workflow. One schema migration required for the new ENUM value.

@micrologs/node v1.0.0 - Official Node.js SDK on npm. Zero dependencies, Node 18+, silent on failure. Wraps every engine endpoint. npm install @micrologs/node.

The project

Micrologs is MIT licensed and open source.

GitHub: github.com/OmDongaonkar03/Micrologs

Node SDK: npmjs.com/package/@micrologs/node

Python and Laravel SDKs are the open contribution if that's your stack.

Built a Self-Hostable Plausible + Sentry Alternative in One Day

Om Dongaonkar — Fri, 27 Feb 2026 21:29:46 +0000

I Built a Self-Hostable Plausible + Sentry Alternative in One Day - That Runs on Shared Hosting

I worked on projects that run on shared hosting. PHP + MySQL, no root access. It's a real environment that a lot of developers actually ship to - and almost no tooling is built for it.

But every analytics or error tracking tool I looked at assumed you had a VPS at minimum, or were happy paying a SaaS bill every month. Plausible is great - but it's paid per site, and self-hosting it means Docker, which means a VPS. Sentry's free tier is generous until it isn't. And there was a hard requirement: no third-party services touching user data.

So I built one. In a day. It's called Micrologs.

What it does

Drop one script tag on your site:

<script
  src="https://yourdomain.com/snippet/micrologs.js"
  data-public-key="your_public_key"
  data-environment="production"
  async>
</script>

From that point, you get:

Pageviews, sessions, unique visitors, bounce rate
Country / region / city breakdown (via local MaxMind GeoLite2 — no runtime API calls)
Device, OS, browser breakdown
Referrer categorization — organic, social, email, referral, direct
UTM campaign tracking
JS errors auto-caught — window.onerror and unhandledrejection, grouped by fingerprint
Manual error tracking from any backend over a single HTTP call
Audit logging
Tracked link shortener with click analytics

All of it hits your own database. Nothing leaves your server.

The constraint that shaped everything

Shared hosting means no Redis, no background workers, no daemons, no WebSockets. You get PHP and MySQL and that's it.

This forced some interesting decisions.

Rate limiting without Redis. Most rate limiters use Redis or a DB table with a timestamp. I went file-based — append-only .req files, one per request, inside a per-IP directory. Counting recent requests = counting files newer than the window. No locking, no DB writes on every request, works on any host.

// Count recent attempts — each file is one request
foreach (glob($userDir . "/*.req") as $file) {
    if ($now - filemtime($file) <= $windowSeconds) {
        $attempts++;
    } else {
        @unlink($file); // clean up expired ones while we're here
    }
}

Cleanup runs probabilistically — 1% chance on each request. No cron job needed.

Geolocation without API calls. MaxMind's GeoLite2 database ships as a .mmdb file you drop on your server. Every lookup is local. Zero latency overhead, zero external dependency at runtime.

Visitor identification without being creepy. No raw IPs stored, ever. IPs are SHA-256 hashed with a salt immediately on ingestion. For visitor tracking, a UUID is stored in a cookie for 365 days. If the cookie gets cleared, a canvas fingerprint kicks in as a fallback to re-identify the same visitor — then re-associates the new cookie hash so the next visit is seamless again.

The architecture is designed in stages

v1 is a clean REST API — works on shared hosting, zero extra infrastructure.

v2 will add Redis caching, async queuing, and webhook alerts — opt-in for people who have a VPS.

v3 will add WebSockets and a live dashboard feed — opt-in for people who want realtime.

The key decision: each stage is strictly opt-in. Shared hosting users will never be broken by what VPS users unlock. v1 will always work on v1 infrastructure.

Some implementation details worth talking about

Error grouping by fingerprint. This is how Sentry works and it's the right approach. When an error comes in, I hash project_id + error_type + message + file + line into a SHA-256 fingerprint. Same error fires 1000 times — 1 group, 1000 occurrences. If you mark an error as resolved and it fires again, it automatically reopens.

$fingerprint = hash(
    "sha256",
    $projectId . $errorType . $message . $file . ($line ?? "")
);

Public key vs secret key separation. The JS snippet uses a public key — safe to expose in the browser, locked to a whitelist of allowed domains. Analytics queries and link management use a secret key — server-side only, never in frontend code. One install supports multiple projects, each with their own key pair.

SPA support in the snippet. History-based routing doesn't trigger page loads, so pushState and replaceState get patched to fire pageviews on navigation. popstate and hashchange are also handled.

history.pushState = function () {
    _push.apply(this, arguments);
    onUrlChange();
};

Bot filtering. UA string matching is obvious, but real browsers always send Accept-Language and Accept headers. If those are missing, it's a bot or a script regardless of what the UA says.

What the API looks like

curl https://yourdomain.com/api/analytics/visitors.php?range=30d \
  -H "X-API-Key: your_secret_key"

{
  "success": true,
  "data": {
    "unique_visitors": 1842,
    "total_pageviews": 5631,
    "total_sessions": 2109,
    "bounce_rate": 43.2,
    "over_time": [
      { "date": "2026-01-28", "pageviews": 178, "unique_visitors": 91 },
      { "date": "2026-01-29", "pageviews": 204, "unique_visitors": 113 }
    ]
  }
}

It's an engine, not a dashboard. The data comes back as JSON — what you do with it is up to you. Build a dashboard, pipe it into Grafana, query it from your admin panel, whatever fits your stack.

Stack

PHP 8.1+
MySQL 8.0+ / MariaDB 10.4+
MaxMind GeoLite2 (local .mmdb file)
Vanilla JS snippet, zero dependencies, ~3KB

No Node, no Docker, no Redis, no build step. Clone it, import the schema, fill in the env file, drop the snippet. That's the entire setup.

It's already in production

We shipped it internally at the company the same day I built it. It's tracking real traffic right now. That's the other reason for the shared hosting constraint — it wasn't a hypothetical, it was the actual target environment.

Open source, MIT

GitHub: github.com/OmDongaonkar03/Micrologs

If you're on shared hosting, running a privacy-first product, or just tired of paying for tools you could own — give it a try. Issues and PRs are open.

v2 is next. Webhooks for error alerts, Redis caching as opt-in, async queuing. If you have thoughts on what matters most, open an issue.