DEV Community: Lambo Poewert

How I Built a Profitable Solana Intelligence Platform on a Single Server — €132/month

Lambo Poewert — Tue, 21 Apr 2026 08:44:14 +0000

How I Built a Profitable Solana Intelligence Platform on a Single Server — €132/month

Two months ago I started building MadeOnSol, a real-time trading intelligence platform for Solana. Today it processes 22,000+ API calls, tracks 1,000 KOL wallets across 11 DEXes, scores 17,000+ token deployers, and indexes 1.1 million buyer records.

It runs on a single dedicated server. It's profitable. Here's the full technical breakdown.

The Stack

Framework: Next.js (App Router, SSG)
Database: Self-hosted Supabase (PostgreSQL + Auth)
Styling: Tailwind CSS
Real-time data: Dual gRPC streams via Yellowstone (Triton) from Constant-K validator nodes
Process manager: PM2
Reverse proxy: Nginx
CDN/DNS: Cloudflare (free tier)
Email: Resend
Analytics: Umami (self-hosted)
Payments: USDC and SOL on Solana (no Stripe, no credit cards)

The Server

Hetzner dedicated server, €100/month:

Intel Xeon E-2176G (6 cores / 12 threads, 3.70GHz)
64GB DDR4 ECC RAM
2x Samsung PM983 960GB NVMe in RAID1 (database)
2x Micron 5200 1.92TB SATA SSD in RAID1 (backups + historical data)
1 Gbit unlimited traffic

Plus ~€32/month for two Constant-K gRPC validator nodes (Frankfurt + New York). Total: €132/month.

How the Data Pipeline Works

Solana processes thousands of transactions per second across dozens of DEX programs. I needed to capture every swap in real-time.

gRPC Streams

I use Yellowstone gRPC (by Triton) to subscribe to transaction updates from Solana validators. Two streams run in parallel:

Frankfurt node — primary, low latency for European users
New York node — failover, low latency for US users

Each stream subscribes to 11 DEX program IDs:

const DEX_PROGRAMS = [
  'PumpFun',
  'PumpSwap', 
  'Raydium',
  'Jupiter',
  'Orca',
  'Meteora',
  'LetsBonk',
  'Bags.app',
  // + 3 more
];

When a transaction comes in, the listener:

Parses the instruction data (each DEX has its own format)
Extracts: wallet, token mint, SOL amount, direction (buy/sell), DEX name
Checks against 1,000 tracked KOL wallets (O(1) hash lookup)
Checks against 17,000+ scored deployer wallets
Stores the trade in PostgreSQL
Pushes to active WebSocket subscribers

Detection latency: under 3 seconds from on-chain to API response.

Dual-Region Failover

The two gRPC streams run independently. If Frankfurt drops, New York keeps processing. Reconnection is handled in-process — no PM2 restarts needed.

class GrpcStream {
  async connect() {
    try {
      this.stream = await this.client.subscribe();
      this.stream.on('data', this.handleTransaction);
      this.stream.on('error', () => this.reconnect());
    } catch (err) {
      setTimeout(() => this.connect(), 5000);
    }
  }

  async reconnect() {
    this.stream?.destroy();
    await this.connect();
  }
}

KOL Tracking

We maintain a list of 1,000 Solana KOL (Key Opinion Leader) wallets. For every trade detected, we check if the wallet is a tracked KOL.

The lookup is a simple Set in memory:

const kolWallets = new Set(await loadKolWallets());

function handleTrade(trade) {
  if (kolWallets.has(trade.wallet)) {
    // Store KOL trade, calculate PnL, check coordination
  }
}

Coordination detection: when 3+ KOLs buy the same token within a time window, we flag it as a potential coordination signal.

Deployer Scoring

Every Pump.fun token has a deployer wallet. We track all 17,000+ deployers and score them by:

Bonding rate — what percentage of their tokens graduated from the bonding curve
Lifetime deploys — total tokens launched
Recent performance — last 10 tokens vs lifetime average

Tiers: Elite (50%+ bond rate), Good (30-50%), Average (10-30%), Poor (<10%)

The first 20 buyers on every Pump.fun token are also recorded. Over time this builds a dataset of 1.1 million+ buyer records that reveals which wallets consistently buy early on winning tokens.

Database Optimization

Materialized Views

The KOL leaderboard and deployer stats are expensive queries (joins + aggregations across millions of rows). Running them on every API request would kill performance.

Solution: materialized views refreshed by pg_cron.

CREATE MATERIALIZED VIEW kol_pairs_summary AS
SELECT wallet, token_mint, 
       count(*) as trade_count,
       sum(sol_amount) as total_volume
FROM kol_trades
GROUP BY wallet, token_mint;

-- Refresh every 5 minutes
SELECT cron.schedule('refresh-kol-pairs', '*/5 * * * *', 
  'REFRESH MATERIALIZED VIEW CONCURRENTLY kol_pairs_summary');

Result: /kol/pairs endpoint went from 500ms to 5ms. 100x improvement.

Connection Pooling

Self-hosted Supabase includes Supavisor for connection pooling. PostgreSQL's process-per-connection model means 200 connections = 200 OS processes. Supavisor multiplexes thousands of API requests through a smaller pool of actual database connections.

API Architecture

Three tiers:

Tier	Price	Rate Limit	Features
Free	$0	200/day	REST endpoints
Pro	$49/mo	10,000/day	REST + 1 WebSocket + 3 webhooks
Ultra	$149/mo	100,000/day	REST + 3 WebSocket + DEX firehose + 10 webhooks

Authentication: Bearer token (msk_ prefixed API keys). Rate limiting: sliding window counter in PostgreSQL (considering Redis for this when load increases).

Payments: USDC or SOL on Solana. No Stripe integration. Users connect their wallet, send payment to our treasury, and the API verifies the transaction on-chain.

WebSocket & DEX Firehose

The DEX Firehose streams every swap across all 11 DEXes via WebSocket. Users subscribe with server-side filters:

{
  "stream": "dex_trades",
  "filters": {
    "dexes": ["pumpfun", "raydium"],
    "min_sol_amount": 5,
    "action_types": ["buy"]
  }
}

The server checks each incoming trade against all active subscriptions and only pushes matching events. One gRPC stream in, many filtered WebSocket streams out.

SEO: 9 to 7,652 Indexed Pages

Programmatic SEO at scale:

1,000+ tool pages with unique descriptions
Comparison pages ("Tool A vs Tool B")
Alternatives pages ("Best X alternatives")
Best-of pages per category
Schema markup, proper meta tags, XML sitemap

Google indexed 94% of the sitemap. Bing's AI has cited the site 3,400+ times. ChatGPT and DuckDuckGo send referral traffic.

The insight: AI search engines cite structured, detailed, honest content automatically. I didn't optimize for AI — I just built useful pages.

Scraper Defense

With 7,652 indexed pages and growing traffic, scrapers showed up. Asian residential proxies running headless Chrome inflated the bounce rate from 54% to 91%.

Defense layers:

Cloudflare Bot Fight Mode — catches obvious bots
Cloudflare firewall rules — challenge traffic from VN/HK/JP/ID without a search engine referrer
Nginx rate limiting — per-IP request caps
Supabase RLS — intelligence data (KOL trades, deployer scores) requires authentication

The tool directory is public (it's SEO content), but the paid data is gated.

Security Audit Findings

Ran a full security audit in month 3. Key findings:

Critical: Missing Row Level Security on payment-related tables. Fixed with a migration adding RLS policies.
Critical: SSRF in webhook delivery — user-supplied URLs weren't validated. Fixed by reusing existing isPrivateUrl() validation.
High: Unauthenticated routes using admin Supabase client (bypassing RLS). Data was intentionally public, but pattern was risky.
Medium: 50+ any types from untyped Supabase queries. Fixed by generating types with supabase gen types typescript.

Capacity Planning

Current load: ~2,250 API calls/day (0.03 requests/second).

Server can handle conservatively 17 million calls/day (200 requests/second mixed workload). That's 7,500x current usage.

Bottleneck order:

PostgreSQL connections (fix: PgBouncer)
CPU contention between gRPC + API + DB (fix: split servers)
WebSocket file descriptors (fix: increase ulimit)

Memory, disk I/O, and network are not bottlenecks.

Scaling plan: this single server handles up to 500-1,000 active API users. When revenue justifies it, split into a database server (keep the Xeon) and a cheap app server (~€15/month).

Results After 2 Months

MRR: $196 (4 Pro subscribers, profitable)
Registered developers: 45
API calls: 22,000+
Data indexed: 1.1M buyer records, 161K wallets, 17K deployers
Google indexed pages: 7,652
AI citations: 3,400+
Infrastructure cost: €132/month
Marketing spend: €0
Team size: 1

The entire platform — real-time gRPC streams, PostgreSQL, Next.js, WebSocket server, API, analytics — runs on a single €100/month dedicated server and is profitable.

Key Takeaways

Self-hosting is viable for SaaS. Supabase, PostgreSQL, Next.js on a dedicated server gives you full control at a fraction of cloud costs.
Materialized views solve most performance problems. Before reaching for Redis, try pg_cron + materialized views.
Programmatic SEO works if the content is useful. 7,652 pages indexed because each one answers a real question.
AI search is a real distribution channel. 3,400 citations without optimization.
Crypto payments reduce friction. USDC on Solana is faster than Stripe for our audience.
Don't scale prematurely. One server handles 7,500x our current load. Scale when you need to, not when you think you might.

If you're building a data-intensive SaaS and wondering whether to go cloud or self-host, the math is clear: €132/month for a server that handles millions of daily requests vs $500+/month for equivalent cloud infrastructure.

Happy to answer questions about any part of the stack.

madeonsol.com

Build a Solana KOL Copy-Trading Bot with Real-Time Webhooks

Lambo Poewert — Fri, 03 Apr 2026 18:42:58 +0000

Every profitable Solana trading bot has one thing in common: speed. The faster you know a KOL bought, the faster you can follow.

Most APIs make you poll every few seconds. That wastes requests, adds latency, and burns your rate limit. The MadeOnSol API now supports webhooks and WebSocket streaming — your server gets notified the instant a trade happens.

In this post I'll show you how to:

Set up a webhook to receive KOL trades in real-time
Verify the HMAC signature to prove it's authentic
Build a simple Express server that logs trades as they happen

What is MadeOnSol?

MadeOnSol tracks 946 Solana KOL wallets in real-time via dual gRPC streams across 9 DEX programs (Pump.fun, Raydium, Jupiter, Orca, etc.). It also monitors 6,700+ Pump.fun deployers and classifies them by bonding success rate.

The API is available on RapidAPI with Free, Pro ($49/mo), and Ultra ($149/mo) tiers.

Step 1: Get your API key

Step 2: Register a webhook

const API_KEY = "your-rapidapi-key";
const HOST = "madeonsol-solana-kol-tracker-tools-api.p.rapidapi.com";

const res = await fetch("https://madeonsol.com/api/v1/webhooks", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "x-rapidapi-key": API_KEY,
    "x-rapidapi-host": HOST,
  },
  body: JSON.stringify({
    url: "https://your-server.com/webhooks/madeonsol",
    events: ["kol:trade", "deployer:alert"],
    filters: {
      min_sol: 1, // Only trades >= 1 SOL
    },
  }),
});

const data = await res.json();
console.log("Webhook ID:", data.webhook.id);
console.log("Secret:", data.webhook.secret); // Save this! Only shown once.

The secret is an HMAC-SHA256 key. Every webhook delivery includes an X-MadeOnSol-Signature header — you use the secret to verify it.

Available events

Event	Description
`kol:trade`	A KOL wallet buys or sells a token
`kol:coordination`	Multiple KOLs converge on the same token
`deployer:alert`	A tracked deployer launches a new token
`deployer:bond`	A tracked deployer's token graduates the bonding curve

Available filters

Filter	Type	Description
`min_sol`	number	Minimum SOL amount (for kol:trade)
`action`	string	`"buy"` or `"sell"` only
`kol_name`	string	Filter by specific KOL name
`deployer_tier`	string[]	Filter by deployer tier: `["elite", "good"]`
`min_kols`	number	Minimum KOL count (for kol:coordination)

Step 3: Build your webhook receiver

Here's a minimal Express server that receives and verifies webhook payloads:

import express from "express";
import crypto from "crypto";

const app = express();
app.use(express.json());

const WEBHOOK_SECRET = "your-webhook-secret-from-step-2";

app.post("/webhooks/madeonsol", (req, res) => {
  // 1. Verify HMAC signature
  const signature = req.headers["x-madeonsol-signature"] as string;
  const expected = crypto
    .createHmac("sha256", WEBHOOK_SECRET)
    .update(JSON.stringify(req.body))
    .digest("hex");

  if (signature !== expected) {
    console.warn("Invalid signature — rejecting");
    return res.status(401).send("Invalid signature");
  }

  // 2. Process the event
  const { event, data, timestamp } = req.body;

  if (event === "kol:trade") {
    console.log(
      `${data.kol_name} ${data.action.toUpperCase()} ${data.sol_amount} SOL`,
      `→ ${data.token_symbol || data.token_mint.slice(0, 8)}`,
      `at ${timestamp}`
    );

    // This is where you'd trigger your copy-trade logic:
    // await copyTrade(data.token_mint, data.action, data.sol_amount);
  }

  if (event === "deployer:alert") {
    console.log(
      `${data.deployer_tier} deployer launched ${data.token_symbol}`,
      `Bond rate: ${(data.bonding_rate * 100).toFixed(0)}%`
    );
  }

  res.status(200).send("OK");
});

app.listen(3000, () => console.log("Webhook server running on :3000"));

Step 4: Test your webhook

Before waiting for a real trade, send a test payload to make sure everything works:

await fetch("https://madeonsol.com/api/v1/webhooks/test", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "x-rapidapi-key": API_KEY,
    "x-rapidapi-host": HOST,
  },
  body: JSON.stringify({ webhook_id: 1 }),
});

This sends a sample KOL trade event to your URL. If your server responds 200, you'll see { success: true, status_code: 200, response_time_ms: ... }.

Alternative: WebSocket Streaming

If you prefer a persistent connection instead of webhooks, you can use WebSocket streaming:

// 1. Get a streaming token (valid 24 hours)
const tokenRes = await fetch("https://madeonsol.com/api/v1/stream/token", {
  method: "POST",
  headers: {
    "x-rapidapi-key": API_KEY,
    "x-rapidapi-host": HOST,
  },
});
const { token } = await tokenRes.json();

// 2. Connect to WebSocket
import WebSocket from "ws";

const ws = new WebSocket(`wss://madeonsol.com/ws/v1/stream?token=${token}`);

ws.on("open", () => {
  // 3. Subscribe to channels
  ws.send(JSON.stringify({
    type: "subscribe",
    channels: ["kol:trades", "deployer:alerts"],
    filters: { min_sol: 1 },
  }));
});

ws.on("message", (raw) => {
  const msg = JSON.parse(raw.toString());

  if (msg.type === "heartbeat") return; // 30s keepalive

  if (msg.event === "kol:trade") {
    console.log(`${msg.data.kol_name} ${msg.data.action} ${msg.data.sol_amount} SOL`);
  }
});

Connection limits: Pro = 1 concurrent connection, Ultra = 3.

Retry & reliability

MadeOnSol webhooks are built for reliability:

3 retries with exponential backoff (5s, 30s, 2min)
10s timeout per delivery attempt
Auto-disable after 10 consecutive failures (re-enable via PATCH)
Delivery log — check recent deliveries with GET /webhooks/{id}

What can you build with this?

Copy-trading bot — follow KOL buys automatically via Raydium/Jupiter
Telegram/Discord alerts — push KOL trades to a group chat
Analytics dashboard — track KOL performance in real-time
Token screener — filter new tokens by deployer reputation before buying
Multi-KOL detector — get notified when 3+ KOLs buy the same token

SDKs

The MadeOnSol API has SDKs for multiple platforms:

TypeScript: npm install madeonsol-x402
Python: pip install madeonsol-x402
MCP Server (Claude/Cursor): npm install -g mcp-server-madeonsol
ElizaOS Plugin: npm install @madeonsol/plugin-madeonsol
Solana Agent Kit: npm install solana-agent-kit-plugin-madeonsol

I built a free Solana trading API — here's how to use it

Lambo Poewert — Tue, 31 Mar 2026 17:56:47 +0000

I run MadeOnSol, a Solana tool directory. Over the past few months I built infrastructure that tracks 946 KOL (Key Opinion Leader) wallets in real-time and monitors 6,700+ Pump.fun token deployers. I packaged all of it into a public API with a TypeScript SDK.

The free tier gives you 100 calls/day, no credit card. Here's what you can build with it.

Install

npm install madeonsol

import { MadeOnSol } from "madeonsol";

const client = new MadeOnSol({
  apiKey: process.env.RAPIDAPI_KEY!,
});

Get your key from the MadeOnSol API page on RapidAPI.

What's in the API

Three product lines:

KOL Tracker — Real-time trades from 946 tracked Solana influencer wallets. Sub-3-second detection via dual gRPC streams (Frankfurt + New York).

Deployer Hunter — Reputation data for 6,700+ Pump.fun token deployers. Tier classification (elite/good/moderate/rising/cold) based on bonding rates and deployment history.

Tools Directory — 1,000+ Solana tools and dApps, searchable by name or category.

Use case 1: KOL trade alert bot

Track what Solana KOLs are buying in real-time and alert yourself when someone drops serious SOL on a token.

async function pollKolBuys() {
  const { trades } = await client.kol.feed({ limit: 10, action: "buy" });

  for (const trade of trades) {
    if (trade.sol_amount > 5) {
      console.log(
        `${trade.kol_name} bought $${trade.token_symbol} for ${trade.sol_amount} SOL`
      );
      // Send to Telegram, Discord, etc.
    }
  }
}

setInterval(pollKolBuys, 30_000);
pollKolBuys();

You could pipe this into a Telegram bot, Discord webhook, or just log to CSV for later analysis.

Rate limit note: 30-second polling = ~2,880 calls/day. Free tier is 100/day, so increase the interval to 5 minutes for testing, or use a paid plan ($49/mo for 10K calls/day) for production.

Use case 2: Check a deployer before you ape

Before buying a freshly launched Pump.fun token, check if the deployer has a history of tokens that actually bond to Raydium — or if they're a serial rugger.

async function checkDeployer(wallet: string) {
  const { deployer } = await client.deployer.profile(wallet);

  console.log(`Tier: ${deployer.tier}`);
  console.log(`Bond rate: ${(deployer.bonding_rate * 100).toFixed(1)}%`);
  console.log(`Total deployed: ${deployer.total_tokens_deployed}`);
  console.log(`Total bonded: ${deployer.total_bonded}`);

  if (deployer.tier === "elite" || deployer.tier === "good") {
    console.log("Solid track record");
  } else {
    console.log("Proceed with caution");
  }
}

checkDeployer("7xKXtg2CW87d97TXJSDpbD5jBkheTqA83TZRuJosgAsU");

The tier system:

Elite — consistently creates tokens that graduate to Raydium
Good — above-average bonding rate
Moderate/Rising — mixed or new, not a strong signal either way
Cold — low bonding rate, most tokens die on the curve

One API call per token. 100 free calls = 100 deployer checks per day.

Use case 3: Multi-KOL convergence scanner

When 3+ KOLs buy the same token within hours, that's a different signal than one influencer shilling their bags. The coordination endpoint finds these patterns.

async function findConvergence() {
  const { tokens } = await client.kol.coordination({
    period: "24h",
    min_kols: 3,
  });

  for (const token of tokens) {
    const direction = token.net_flow > 0 ? "accumulating" : "distributing";
    console.log(
      `${token.token_symbol}: ${token.kol_count} KOLs, ${direction}`
    );
  }
}

findConvergence();

Filter for only accumulating tokens and sort by KOL count:

const accumulating = tokens
  .filter((t) => t.net_flow > 0)
  .sort((a, b) => b.kol_count - a.kol_count);

Chain them together

The real value is combining all three. Find convergence signals, check deployer reputation, output a ranked list:

async function fullScan() {
  const { tokens } = await client.kol.coordination({
    period: "4h",
    min_kols: 3,
  });

  const results = [];

  for (const token of tokens.filter((t) => t.net_flow > 0)) {
    if (token.deployer_wallet) {
      const { deployer } = await client.deployer.profile(
        token.deployer_wallet
      );
      results.push({
        symbol: token.token_symbol,
        kolCount: token.kol_count,
        deployerTier: deployer.tier,
        bondRate: deployer.bonding_rate,
      });
    }
  }

  const tierOrder = { elite: 4, good: 3, average: 2, poor: 1 };
  results.sort((a, b) => {
    const diff =
      (tierOrder[b.deployerTier] || 0) - (tierOrder[a.deployerTier] || 0);
    return diff !== 0 ? diff : b.kolCount - a.kolCount;
  });

  for (const r of results) {
    console.log(
      `${r.symbol} — ${r.kolCount} KOLs, deployer: ${r.deployerTier} (${(r.bondRate * 100).toFixed(1)}% bond rate)`
    );
  }
}

fullScan();

Each token in the results triggers a deployer lookup, so a scan with 10 tokens = 11 API calls total.

Error handling

try {
  const { deployer } = await client.deployer.profile(wallet);
} catch (error) {
  if (error.status === 404) {
    console.log("Deployer not in database");
  } else if (error.status === 429) {
    console.log("Rate limited — back off and retry");
  } else {
    console.error("Error:", error.message);
  }
}

Full endpoint list

KOL Tracker:

client.kol.feed() — real-time trade feed
client.kol.leaderboard() — PnL rankings
client.kol.wallet(address) — individual KOL stats
client.kol.coordination() — multi-wallet convergence
client.kol.tokenFlow(mint) — KOL flow per token

Deployer Hunter:

client.deployer.stats() — global stats
client.deployer.leaderboard() — ranked deployers
client.deployer.profile(wallet) — deployer details (Pro)
client.deployer.tokens(wallet) — token history (Pro)
client.deployer.alerts() — new launch alerts
client.deployer.alertStats() — alert performance
client.deployer.bestTokens() — top performers
client.deployer.recentBonds() — recent graduations

Tools:

client.tools.search() — search 1,000+ tools

Pricing

Plan	Price	Daily limit
Basic	Free	100
Pro	$49/mo	10,000
Ultra	$149/mo	100,000

Links

If you build something with it, I'd love to see it. Drop a comment or find me on Twitter.

Moved from hosted Supabase to self-hosted on a single VPS — here's what I learned after weeks in production

Lambo Poewert — Fri, 27 Mar 2026 08:23:55 +0000

Most self-hosting guides show you how to get Supabase running. Not many tell you what happens after you've been running it for months with real users and real data. Here's what I've learned.

The project

I built MadeOnSol, a Solana ecosystem directory that tracks 950+ tools across 26 categories. The stack includes 74 Postgres tables, 100k+ real-time trade records, Google OAuth, file storage for 900+ tool logos, and Row Level Security on every table.

It started on Supabase's free hosted tier. Four months ago I moved everything to a self-hosted Docker setup on a Hetzner CPX32 (8GB RAM, 4 vCPU, €15/month). Here's what I'd want to know if I were doing it again.

How much resources does it actually use?

This is the question nobody answers well. The default self-hosted Supabase ships with ~15 containers. I stripped it down to 8 by removing Studio, Edge Functions, Analytics, Vector, Meta, and the Deno cache. None of them were doing anything useful in production.

Here's what the remaining services actually consume:

Service	Memory	What it does
supabase-db	~413 MB	Postgres 15
supabase-kong	~429 MB	API gateway (yes, really)
realtime	~169 MB	WebSocket subscriptions
supabase-storage	~109 MB	File storage
supabase-pooler	~60 MB	Supavisor connection pooling
supabase-rest	~40 MB	PostgREST
supabase-auth	~22 MB	GoTrue (email + Google OAuth)
supabase-imgproxy	~17 MB	Image transforms

Total: ~1.26 GB. On 8GB that leaves plenty of room for a Next.js app, three background services, Nginx, and Umami analytics.

The things that went right

Co-located database performance. With the database on the same machine as the app, API responses went from ~120ms (hosted) to ~30ms. No network hop makes a real difference when your background services are doing batch operations on 100k+ records.

Supavisor connection pooling is solid. Session mode on port 5432 for the Next.js app, transaction mode on port 6543 for background scripts. Set it up once, never thought about it again.

Storage migration was seamless. Copied all files over, updated URLs, and the storage API behaved identically to hosted. No app code changes needed.

Google OAuth just worked. Set the GOTRUE_EXTERNAL_GOOGLE_* environment variables, configured the consent screen, done. One gotcha: I use a manual PKCE flow with localStorage instead of cookies because cross-site cookie loss was causing redirect issues.

Backups went from "nothing" to solid. On the free hosted tier I had zero backups. Now it's pg_dump → gzip → SSH to a separate storage box, running at 3 AM daily with 30-day retention. Peace of mind for ~5 lines of bash.

The things that bit me

Kong uses an absurd amount of memory. 429 MB for an API gateway. It spikes to 600MB+ under load. It's the single biggest memory consumer after Postgres itself. I've considered replacing it with Nginx routing but Kong handles auth middleware that would be painful to replicate.

Realtime goes silently bad. The container reports "healthy" to Docker but stops delivering messages. The only fix is docker compose restart realtime. I now run a health check every 5 minutes that tests actual message delivery, not just the HTTP health endpoint.

JWT rotation will break every active session. I rotated my JWT secret once and every user got stuck in auth loops because their browser cookies had the old token. I wrote middleware that detects stale sb-* cookies and clears them automatically. Also learned the hard way: use docker compose up -d --force-recreate when changing env vars, not docker compose restart — restart doesn't re-read the .env file.

The default docker-compose is a security risk. Ports are bound to 0.0.0.0 by default, which means your Postgres, PostgREST, and Kong are accessible to the entire internet. Change every port binding to 127.0.0.1:PORT:PORT and put Nginx with SSL in front of everything.

Upgrades are a gamble. The self-hosted repo moves fast and I've skipped most updates. My rule: only upgrade if there's a specific bug fix I need. Always pin your Docker image versions.

Security checklist

If you're self-hosting, this is the minimum:

Nginx reverse proxy with Let's Encrypt SSL in front of Kong (port 8000)
UFW firewall allowing only Cloudflare IPs on 80/443
Every Docker port bound to 127.0.0.1
RLS on every table — self-hosting doesn't mean you can skip this
Admin checks via app_metadata.is_admin (not user_metadata, which users can modify themselves)
Rate limiting at both the Nginx and application layer

When it makes sense (and when it doesn't)

Self-host if you're comfortable with Postgres, your project is outgrowing the free tier, you want direct database access for cron jobs and background processing, or you want full control over backups.

Stay on hosted if you want zero ops overhead, rely on Supabase Studio, don't want to manage Docker/Nginx/SSL, or your project fits comfortably on the free tier.

For me the tipping point was having background services that needed direct Postgres access for heavy batch work. The co-located performance and €15/month flat cost made it an easy call.

The full stack — Supabase, Next.js, three background services, Nginx, and Umami — all runs on a single VPS. Happy to answer questions about any part of the setup.

How I Built a Real-Time KOL Trade Tracker on Solana Using Dual gRPC Streams

Lambo Poewert — Wed, 25 Mar 2026 18:52:32 +0000

I built a real-time KOL wallet tracker that monitors 463 Solana wallets — here's how it works

Every second, hundreds of transactions flow through Solana's DEX programs. Somewhere in that firehose, a whale wallet just bought 50 SOL of a token nobody's heard of. By the time it shows up on a block explorer, the price has already moved.

I built a system that detects these trades in real-time for 463 tracked KOL (Key Opinion Leader) wallets — every buy and sell, within seconds. It's processed over 100,000 trades across 10,900+ unique tokens so far.

Here's how it works.

The Architecture

Kaldera gRPC (Frankfurt) ──┐
                            ├──▶ Parse ──▶ Filter KOL wallets ──▶ PostgreSQL
Kaldera gRPC (New York) ───┘        ▲              │
                                    │              ▼
                              Dedup via        WebSocket
                            tx_signature      fan-out to
                           ON CONFLICT        frontend

The core idea: subscribe to every DEX transaction on Solana via gRPC, filter client-side for wallets we care about, then store and broadcast the trades.

Why gRPC, Not WebSocket or Polling

Most Solana data tools use WebSocket subscriptions (onLogs, onAccountChange) or poll RPC endpoints. Both have problems at this scale:

WebSocket subscriptions on public RPCs have strict limits (usually 100-200 subscriptions). We track 463 wallets across 9 DEX programs — that's way over the limit.
Polling getSignaturesForAddress for 463 wallets would mean ~463 RPC calls every few seconds. You'll hit rate limits instantly.

gRPC (via Yellowstone/Geyser plugins) gives you the full transaction firehose at the commitment level you choose. One subscription, all DEX transactions, filtered client-side:

import Client, { CommitmentLevel } from "@triton-one/yellowstone-grpc";

const DEX_PROGRAMS = [
  "6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P",  // Pump.fun
  "pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA",  // Pump AMM
  "675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8",  // Raydium V4
  "JUP6LkbZbjS1jKKwapdHNy74zcZ3tLUZoi5QNyVTaV4",   // Jupiter V6
  "whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc",   // Orca Whirlpool
  // ... 4 more
];

const stream = await client.subscribe();

stream.write({
  transactions: {
    swaps: {
      accountInclude: DEX_PROGRAMS,
      vote: false,
      failed: false,
    },
  },
  commitment: CommitmentLevel.CONFIRMED,
});

This gives us every confirmed DEX swap. On a typical day, that's ~15,000-20,000 transactions every 30 seconds. We then check if any account in the transaction matches our KOL wallet set.

The Dual-Stream Failover

gRPC connections reset hourly (HTTP/2 GOAWAY frames), and servers occasionally go down for maintenance. With a single stream, you get a gap: disconnect → reconnect → backfill. During that gap, you miss trades.

The fix: run two streams simultaneously from different regions.

const GRPC_REGIONS = [
  { url: process.env.KALDERA_GRPC_URL, label: "Frankfurt" },
  { url: process.env.KALDERA_GRPC_URL_FALLBACK, label: "New York" },
];

const streams = new Map();

await Promise.allSettled(
  GRPC_REGIONS.map(region => connectRegion(region))
);

Both streams fire simultaneously. When Frankfurt disconnects for its hourly h2 reset, New York keeps detecting trades. When New York reconnects, Frankfurt covers it. Zero gaps.

"But won't you get duplicate trades?" Yes — and that's fine. PostgreSQL handles it:

INSERT INTO kol_trades (kol_wallet_id, token_mint, action, sol_amount, tx_signature, ...)
ON CONFLICT (tx_signature) DO NOTHING

The tx_signature is unique per transaction. Duplicates are silently dropped. In practice, both streams process ~18,000 tx each per 30-second window, but only unique trades get stored.

Parsing the Swap

A DEX transaction doesn't come with a nice label saying "buy 2.5 SOL of TOKEN_X." You have to reconstruct the trade from raw balance changes:

function parseSwap(txUpdate) {
  const meta = txUpdate.transaction?.transaction?.meta;
  const msg = txUpdate.transaction?.transaction?.message;

  // Build full account key list (static + loaded)
  const accountKeys = [
    ...msg.accountKeys.map(k => bs58.encode(Buffer.from(k))),
    ...meta.loadedWritableAddresses.map(k => bs58.encode(Buffer.from(k))),
    ...meta.loadedReadonlyAddresses.map(k => bs58.encode(Buffer.from(k))),
  ];

  // Find our KOL wallet in the transaction
  let kolAddress = null;
  for (const key of accountKeys) {
    if (kolWalletSet.has(key)) {
      kolAddress = key;
      break;
    }
  }
  if (!kolAddress) return null;

  // SOL balance change = sell amount or buy cost
  const preSol = Number(meta.preBalances[walletIndex]) / 1e9;
  const postSol = Number(meta.postBalances[walletIndex]) / 1e9;
  const solChange = postSol - preSol;

  // Token balance changes (SPL tokens)
  for (const post of meta.postTokenBalances) {
    if (post.owner !== kolAddress) continue;
    const pre = meta.preTokenBalances.find(
      p => p.accountIndex === post.accountIndex
    );
    const change = (post.uiTokenAmount?.uiAmount ?? 0)
                 - (pre?.uiTokenAmount?.uiAmount ?? 0);
    if (Math.abs(change) > 0.000001) {
      tokenChanges.push({ mint: post.mint, change });
    }
  }

  // Positive token change + negative SOL change = buy
  // Negative token change + positive SOL change = sell
  const action = primaryToken.change > 0 ? "buy" : "sell";
}

The key insight: compare preBalances vs postBalances for SOL, and preTokenBalances vs postTokenBalances for SPL tokens. The wallet that gained tokens and lost SOL is buying. Vice versa for selling.

Handling the Edge Cases

Token metadata isn't available immediately. When a token launches on Pump.fun, the Metaplex metadata might not be queryable for a few seconds. We store trades with token_name: null and retry every 2 minutes:

setInterval(async () => {
  const { rows } = await pool.query(
    `SELECT DISTINCT token_mint FROM kol_trades
     WHERE token_name IS NULL
     AND traded_at > NOW() - INTERVAL '24 hours' LIMIT 20`
  );
  for (const { token_mint } of rows) {
    const meta = await getTokenMeta(token_mint);
    if (meta?.name) {
      await pool.query(
        `UPDATE kol_trades SET token_name = $1, token_symbol = $2
         WHERE token_mint = $3 AND token_name IS NULL`,
        [meta.name, meta.symbol, token_mint]
      );
    }
  }
}, 2 * 60 * 1000);

RPC can go down. Metadata fetches use a circuit breaker — after 5 consecutive failures, we pause RPC calls for 30 seconds instead of hammering a dead endpoint.

Backfill on reconnect. When the service starts (or both streams were down), we check the last 10 transactions of recently active wallets via getSignaturesForAddress to catch anything missed.

The Watchdog

Each stream has an independent watchdog. If no data arrives for 60 seconds, the stream is considered dead and gets force-reconnected:

setInterval(() => {
  for (const region of GRPC_REGIONS) {
    const state = streams.get(region.label);
    const silenceMs = Date.now() - state.lastAliveAt;
    if (silenceMs > 60000 && state.stream) {
      log(`[${region.label}] Watchdog: forcing reconnect`);
      state.stream.cancel();
      state.stream = null;
      scheduleReconnect(region); // exponential backoff
    }
  }
}, 30000);

The heartbeat file (/tmp/kol-tracker-heartbeat) gets picked up by our health monitor, which can auto-restart the PM2 process if things go truly sideways.

Results

The system runs 24/7 on a single Hetzner VPS (8GB RAM), tracking 463 KOL wallets across 9 DEX programs. Some numbers:

100,000+ trades detected so far
~21,000 trades per day on active days
10,900+ unique tokens tracked
<3 second latency from on-chain confirmation to database
Zero gaps since implementing dual-stream failover
~200MB memory footprint per stream

The whole thing is a single Node.js process managed by PM2. No Kubernetes, no message queues, no microservices. Sometimes the simplest architecture is the right one.

Stack

gRPC: @triton-one/yellowstone-grpc (Yellowstone Geyser plugin client)
Database: PostgreSQL (self-hosted Supabase)
Process: PM2 on Ubuntu
Infrastructure: Kaldera gRPC nodes (Frankfurt + New York)
Frontend: Next.js with WebSocket fan-out for real-time updates

The KOL Tracker is part of madeonsol.com/kol-tracker — a directory of 950+ Solana tools I've been building. The live leaderboard shows who's profiting and who's not, updated in real-time.

If you're building on Solana and want to work with gRPC streams, the Yellowstone plugin is incredible. Just make sure you handle disconnects gracefully — the firehose is powerful but unforgiving.

# Building the Largest Solana Tool Directory — Progress Report

Lambo Poewert — Mon, 23 Mar 2026 19:12:26 +0000

A month ago I started building MadeOnSol, a curated directory and intelligence platform for the Solana ecosystem. This is a full progress report — what I shipped, what's working, what I learned, and where things stand today.

What is MadeOnSol

MadeOnSol is a free, unbiased directory of Solana tools — trading bots, DEXs, wallets, DeFi protocols, analytics platforms, developer tools, and more. Every listing has honest descriptions, pros/cons, pricing, and alternatives. No paid rankings.

On top of the directory, I built a set of intelligence tools that track on-chain activity in real time.

What I shipped

The directory

815 tools across 26 categories
Each tool has its own page with description, features, pros/cons, pricing model, alternatives, and comparison links
Category pages, best-of pages, and comparison pages (Axiom vs BullX, Phantom vs Solflare, etc.)
Community reviews with a monthly reward system — top 3 contributors earn 0.25 SOL each

Intelligence tools

Deployer Hunter — tracks 7,197+ pump.fun deployers in real time. Each deployer is scored by graduation rate (how often their tokens bond to Raydium). Deployers are classified as Elite, Good, or Rising. The feed shows live deployments from tracked deployers, filterable by tier.

KOL Tracker — monitors 462 top Solana wallets, showing what they actually buy and sell on-chain. Includes a PnL leaderboard, top buys feed, hot tokens (tokens with multiple KOL buyers), and a compare tool.

The connection — Deployer Hunter and KOL Tracker now feed each other. When a tracked deployer launches a token and KOLs start buying, you see it on both feeds instantly. Every KOL profile has a Deployer Score showing what % of their buys come from tracked deployers.

TikTok Trend Detector — scans viral TikTok videos that could become the next memecoin. Updates every few minutes, scored by the community.

Token Launcher — launch tokens on pump.fun with MEV protection, multi-wallet distribution, and automated sell strategies.

Content

120+ blog guides — trading bot comparisons, DeFi explainers, bridge breakdowns, step-by-step tutorials
Glossary pages for Solana-specific terms
Bot fee calculator and RPC comparison tools

Community features

Review system with replies
Private messaging between users
Achievement badges and reputation points
Weekly leaderboard with SOL rewards
Tool watchlists and follow system
Tool claim system for project teams

The numbers

Metric	Value
Tools listed	815
Categories	26
Blog guides	120+
Deployers tracked	7,197
KOL wallets monitored	462
Pages on site	~1,580
Google indexed pages	256
Linking websites	15
Registered users	10
Monthly cost	~€140
Revenue	$0

Tech stack

Component	Tool
Frontend	Next.js (App Router, SSG)
Database	Supabase / PostgreSQL
Real-time data	gRPC stream via Kaldera RPC
Hosting	Hetzner VPS (CX23)
Email	Resend
DNS	Cloudflare
Analytics	Self-hosted Umami
Coding partner	Claude

I migrated from Plausible Cloud (€16/month) to self-hosted Umami to save costs. All traffic stats are public at madeonsol.com/stats.

SEO — the real challenge

This is where I've learned the most.

MadeOnSol has ~1,580 pages. Google has indexed 256 of them. The other 1,374 are stuck in "Discovered — currently not indexed." Google knows the URLs exist but won't spend crawl budget on a low-authority domain.

What didn't work

Buying cheap backlinks. I evaluated Fiverr packages, Reddit offers, and someone who offered 100 .edu profile backlinks from random universities. All turned out to be spam farms with zero relevance to Solana. One link from a relevant crypto site is worth more than 1,000 of those.

Writing more content without backlinks. I spent weeks adding tools and publishing guides thinking traffic would follow. It didn't. Without external links, Google won't crawl deep enough to find most of your pages.

What is working

Submitting to real, relevant directories and platforms:

DappRadar — submitted as a Web3 project (under review)
DEV.to — technical deep dive on the Deployer Hunter architecture
Medium — building in public story
Indie Hackers — weekly progress updates
Launching Next — startup listing
Product Hunt, AlternativeTo, BetaList — in the pipeline

Since starting this backlink sprint, indexed pages jumped from 205 to 256 in two days. First visitors are coming in from Google, DuckDuckGo, Bing, Reddit, and X.

Key SEO lesson

Backlinks first, content second. If I started over, I'd spend the first two weeks building 20 legitimate backlinks before writing a single blog post. Domain authority unlocks everything — without it, Google ignores your content no matter how good it is.

What's working beyond SEO

Organic discovery. People are finding Deployer Hunter and KOL Tracker without me promoting them. Wallet scans happen daily from users I've never interacted with.

Unprompted tool claims. GetBlock (24K X followers) found their listing and claimed it organically. No outreach from my side.

The intelligence tools are the moat. The directory alone is useful but not unique. Deployer Hunter tracking 7,197 deployers with historical data, connected to KOL Tracker monitoring 462 wallets — that dataset grows daily and gets harder to replicate.

Public stats build trust. Having all traffic data public at madeonsol.com/stats shows I have nothing to hide. When the time comes to approach sponsors, this is proof.

What I'd do differently

Start backlink work from day one — not after building 1,580 pages
Launch with fewer features — I built five intelligence tools, then removed three. Should have started with two
Ignore anyone selling cheap backlinks — if it sounds too good to be true, it's spam

What's next

Reaching 20+ dofollow linking domains (currently at 2)
Product Hunt launch
Solana ecosystem GitHub PR (solana-labs/ecosystem repo)
Outreach to projects listed on MadeOnSol for backlinks
Monthly data reports using Deployer Hunter + KOL Tracker data
First revenue from affiliate links on trading bot pages

Try it

Everything is free, no registration required to browse:

🔗 MadeOnSol — the directory
🔗 Deployer Hunter — track pump.fun deployers
🔗 KOL Tracker — track what smart money buys
🔗 TikTok Trends — viral videos → memecoins
🔗 Live Stats — public traffic dashboard

Happy to answer any questions about the build, the Solana ecosystem, or the SEO grind. Building in public, one day at a time.

How I built a real-time pump.fun deployer tracker and connected it to KOL wallet monitoring on Solana

Lambo Poewert — Sun, 22 Mar 2026 10:00:09 +0000

How I built a real-time pump.fun deployer tracker and connected it to KOL wallet monitoring on Solana

I run MadeOnSol, a Solana ecosystem directory. Over the past few months I built two intelligence tools on top of it — Deployer Hunter and KOL Tracker — and recently connected them so they feed each other signals in real time.

This post covers the architecture, the data pipeline, and what I learned building it as a solo developer.

The problem

On Solana, thousands of tokens launch daily on pump.fun. Most are worthless. A few graduate to real liquidity.

The question every trader asks is:

"Did a good deployer just launch something, and are smart wallets buying it?"

Before I built this, answering that question meant manually checking deployer wallets, cross-referencing with KOL wallets, and hoping you caught the signal in time. I wanted to automate the entire pipeline.

Deployer Hunter — tracking 7,197+ deployers

The core idea is simple: track every pump.fun deployer, score them by their graduation rate (how many of their tokens actually bond to Raydium), and surface the ones with real track records.

Data ingestion

I use a gRPC stream connected to Solana via a Kaldera RPC endpoint. This gives me real-time transaction data as it hits the chain — no polling, no delays. Every time a token is created on pump.fun, I capture the deployer address, token mint, and timestamp.

Scoring logic

Each deployer gets two scores:

Recent rate — graduation % of their last N tokens
Lifetime rate — graduation % across all their tokens

Deployers are classified into tiers:

Tier	Meaning
🏆 Elite	Consistently high graduation rate across many deploys
✅ Good	Solid recent track record
🌟 Rising	New but showing promise

Storage

Everything goes into Supabase (PostgreSQL). Deployer profiles, token history, graduation events, and peak market caps are all stored and queryable. Each deployer gets their own profile page with full history.

The feed

Deployer Hunter shows a live feed of new deployments from tracked deployers, filterable by tier. When an Elite deployer launches something, it shows up immediately.

Currently tracking 6,366 deployers with 194 bonds today at a 6.3% graduation rate.

KOL Tracker — 462 wallets monitored

KOL Tracker watches what the biggest Solana wallets are actually buying on-chain. Not what they tweet — what they trade.

Wallet monitoring

I maintain a curated list of 462 KOL wallets. The system monitors their transactions in real time using the same gRPC infrastructure. When a tracked wallet buys or sells a token, it appears in the live feed within seconds.

Features

Live feed of all KOL buys and sells
PnL leaderboard — who's actually profitable
Top buys — which tokens are getting the most KOL attention
Hot tokens — tokens with multiple KOL buyers
Compare tool to put KOLs side by side

Users can suggest new KOLs to track. I verify the wallet before adding it.

The connection — where it gets interesting

The real power came from connecting these two systems. Now:

When a tracked deployer launches a token → Deployer Hunter shows it
When KOLs start buying that same token → KOL Tracker shows it
Both feeds cross-reference each other — you see KOL interest on a deployer's launch, and deployer quality on a KOL's buy

Every KOL profile now has a Deployer Score — what percentage of their buys come from tokens launched by tracked deployers. This tells you whether a KOL is buying from proven deployers or chasing random launches.

The signal chain becomes:

Good deployer launches → KOLs buy → you see it on both feeds simultaneously.

Tech stack

Component	Tool
Frontend	Next.js (App Router, SSG where possible)
Database	Supabase / PostgreSQL
Real-time data	gRPC stream via Kaldera RPC
Hosting	Hetzner VPS (CX23)
Email	Resend
DNS	Cloudflare

Total infrastructure cost: ~€140/month.

What I learned

gRPC > polling

The difference between polling an RPC endpoint every few seconds and having a real-time gRPC stream is massive. You catch deploys and buys within the same slot they happen.

Scoring is harder than detection

Detecting a new deploy is easy. Deciding whether a deployer is "good" requires careful threshold tuning.

Early on, tokens were showing as "bonded" with peak market caps of $3-5K — impossible since bonding requires ~$69K. Turned out to be false positives in the bonding detection logic. Still refining this.

Kill features that dilute focus

I previously had five intelligence tools. I removed three (Wallet X-Ray, CTO Radar, Token Scanner) to focus on Deployer Hunter + KOL Tracker. The product is stronger for it.

The data is the moat

Anybody can build a UI. The value is in 7,197+ deployer profiles with historical data and 462 tracked KOL wallets with real PnL. That dataset grows every day and gets harder to replicate.

What's next

Publishing monthly data reports using this pipeline (graduation rates, KOL accuracy, deployer trends)
Improving bonding detection to eliminate false positives
Building a TikTok-to-Token analyzer that correlates viral TikTok content with token launches

Both tools are free and require no registration to browse:

🔗 Deployer Hunter
🔗 KOL Tracker

Happy to answer any questions about the architecture or the Solana data pipeline.