DEV Community: Ajay Kumar

open source AI App builder with DB

Ajay Kumar — Tue, 01 Sep 2026 08:07:25 +0000

pandastack-io / riff

AI App Builder - powered by pandastack.ai

⑂ Riff

Prompt → a running full-stack app. Then fork it.

Open-source, self-hostable Lovable / v0 / bolt — where every app runs in a real Firecracker microVM, stays live forever for ~$0, and you can fork the running app and its database to explore variations in parallel.

Describe an app. Riff builds it and runs it live on a real microVM in about a second. Then — the part nothing else can do — fork the running app into N live variations, compare them side by side, and keep the one you like. Each branch is a genuine isolated VM (with its own cloned Postgres), not a browser tab.

Why Riff exists

Lovable, v0, and bolt are closed SaaS, and every one of them hits the same walls:

Their wall	How Riff removes it
Toy/ephemeral backends (browser sandboxes, WebContainers)	Real Firecracker microVMs — any framework, real servers, background jobs,

…

View on GitHub

Open-source sandboxes for AI agents and code execution.

Ajay Kumar — Tue, 01 Sep 2026 05:47:57 +0000

pandastack-io / pandastack-ai

Open-source sandboxes for AI agents and code execution.

PandaStack

Open-source Firecracker microVM sandboxes and managed PostgreSQL, self-hosted.

60-second quickstart

git clone https://github.com/pandastack-io/pandastack-ai
cd pandastack-ai
bash scripts/mac-local-e2e.sh
open http://localhost:3000

Create a sandbox from the local API:

curl -sS http://localhost:8080/v1/sandboxes \
  -H 'Authorization: Bearer pds_local_dev_token' \
  -H 'Content-Type: application/json' \
  -d '{"template":"base"}'

Exec a command in it:

curl -sS http://localhost:8080/v1/sandboxes/<id>/exec \
  -H 'Authorization: Bearer pds_local_dev_token' \
  -H 'Content-Type: application/json' \
  -d '{"cmd":"echo","args":["hello"]}'

What it does

PandaStack is two things on one control plane: disposable Firecracker microVM sandboxes for AI agents and untrusted code, and managed PostgreSQL 16 instances that run in microVMs of their own.

Firecracker microVM sandboxes with strong process and kernel isolation.
Managed PostgreSQL 16 databases (Beta) — a real, durable database in its own microVM, with a native postgres:// URL in seconds, continuous WAL archiving, and restore-based failover onto a healthy…

View on GitHub

We made a cold start take 164 milliseconds

Ajay Kumar — Tue, 01 Sep 2026 05:22:44 +0000

Vercel Fluid works to avoid the cold start — pre-warming and sharing instances so you rarely hit one. We took the other path: scale fully to zero — the sandbox is deleted — then thaw a frozen microVM in the time it takes to read this sentence.

Introducing Thaw — sub-second cold restore · PandaStack

A frozen microVM, thawed in ~164ms. True scale-to-zero ($0 idle) and a sub-second cold restore — and the engineering behind it.

pandastack.ai

Learn how AI Agent sandboxes are shaping the world

Ajay Kumar — Tue, 01 Sep 2026 05:21:50 +0000

AI agents are moving beyond chat. They’re writing code, running commands, using browsers, and working with real systems.

But where do you safely let an AI run code it generated itself?

That’s what we’re building with PandaStack — isolated Linux sandboxes for AI agents, powered by Firecracker microVMs.

Give every agent its own environment to experiment, execute, break things, and start fresh.

If you're building coding agents, browser agents, or AI developer tools, take a look:

👉 https://pandastack.ai

Still early, but I think this infrastructure will become a pretty important part of the agent ecosystem.

AI #AIAgents #DevTools #CloudComputing

How we made a cold start take 164ms — introducing Thaw

Ajay Kumar — Tue, 23 Jun 2026 10:02:17 +0000

Every scale-to-zero platform makes the same trade. Scale to zero and you pay nothing while idle — but the next request eats a cold start. Keep something warm and the cold start disappears — but now you're paying for idle capacity. For a decade that's basically been the whole conversation: how do you avoid making a user wait while a machine starts up?

We took a different swing at it. Instead of avoiding the cold start, we made it cheap. On our app-hosting platform, an idle app gets its entire microVM deleted — CPU, RAM, disk, all freed, genuinely zero. And when a request comes in, we thaw a frozen Firecracker microVM back to life in about 164 milliseconds.

This is the story of how — including the part where an earlier version of the idea caused a nasty production incident, which turned out to be the most important thing that happened, because it dictated the entire safe design.

A note on honesty: the numbers here are ours, measured on our production fleet (Firecracker, kernel 6.17). I'll show you exactly what we measured. Anything I say about other platforms is from their public docs.

The two numbers that started it

Before any of this, a scaled-to-zero app on our platform woke by cold-booting from a baked disk image: pull the multi-gigabyte image, boot the kernel, run init, start the app, wait for it to bind its port. Measured end to end, that was about 54 seconds (≈26s image pull, ≈8s boot, ≈20s app start). It's honest — $0 while idle — but 54 seconds is a long time to stare at a spinner.

The other number we already had was 64 milliseconds. That's how long it takes us to restore a baked Firecracker memory snapshot for a base template — the same path that gives our sandboxes a sub-200ms create with no warm pool.

A restore is not a boot. The kernel is already up. Init has already run. The process is already in memory. You're mapping a frozen machine back into existence, not building one from scratch.

So the question wrote itself:

App wake was 54 seconds because it was a boot. Snapshot restore was 64 milliseconds because it wasn't. What would it take to make app wake a restore?

Why we couldn't just snapshot apps already

Because we'd tried something like it, and it bit us. Hard.

An earlier version captured a memory snapshot of a running app. The app would sleep, wake, serve perfectly for the smoke test… and then start throwing filesystem I/O errors hours later. Green deploy, healthy checks, and then EXT4-fs error in the logs long after anyone was watching.

The cause is worth stating precisely, because it's the reason Thaw is shaped the way it is.

A Firecracker memory snapshot captures RAM — and RAM includes the kernel's page cache, the in-memory copy of disk blocks the guest has touched. Our snapshot recorded a pointer to the rootfs, not its bytes. Sleep then deleted that rootfs. On wake we restored the frozen page cache over a blank template disk.

For a while everything served from RAM and looked fine. The instant the guest had to read a block that wasn't cached — or flush a dirty one back — it hit a disk that no longer matched what memory believed was there. Corruption. Hours after a passing smoke test.

vm.mem (frozen page cache)  ──points at──►  rootfs.ext4  ← DELETED
                                              │
                                              ▼
                                       blank template disk
                                              │
                                  first uncached read ──► EXT4-fs error

The lesson wasn't "snapshots are dangerous." It was sharper than that:

A memory snapshot and the disk underneath it are a matched pair. Restore the memory over a different disk and you've built a machine that lies to itself.

Every decision in Thaw exists to make that mismatch impossible.

How Thaw works

Two halves: when we bake the seed, and what the restore lands on.

The bake: one atomic pause, app stopped

We don't bake the seed at deploy time. We bake it the first time the app goes idle — which is the perfect moment, because the app is doing nothing and the sandbox is about to be deleted anyway.

Inside the guest, first we stop the app process and delete its env file. Then, under a single atomic pause, we capture three things from one frozen instant:

vm.mem — the memory image (~2 GB)
vm.state — CPU + device state
clone.ext4 — a byte-for-byte copy of that exact disk (~10 GB)

Two properties fall out of that ordering, and both matter:

The app is stopped before the snapshot. So the memory we capture has no in-flight request, no half-held mutex, no live socket — and crucially, no plaintext secrets (the env file is already gone). It's a quiesced, secret-free machine.
The disk copy happens inside the same pause as the memory snapshot. So the RAM and the disk come from the identical instant. They cannot drift, because there was no time between them in which anything could change.

The result is a "seed" — a complete, frozen microVM, in a few files.

The restore: onto the seed's own disk, never a template

On wake we restore over the seed's own byte-identical disk — the copy taken during that pause — gated by a SHA-256 hash. Never a fresh template clone.

This is the exact line the old incident violated, and making it structurally impossible is the entire point. The frozen page cache in the restored memory is now sitting over precisely the disk it was cached from. There's nothing for it to lie about.

Then we hand off to a fresh process. The app was stopped in the seed, so on restore we re-deliver the environment (including any secrets that rotated while the app was asleep — they're applied at wake, never frozen into the snapshot) and start the app as a brand-new process on the now-warm machine. Before routing a single request to it, a liveness gate does a write → fsync → read round-trip — forcing a real disk touch. If memory and disk were ever going to disagree, that's where it surfaces, and we fall back rather than serve corruption.

So Thaw is explicitly not "resurrect your exact running process mid-request." We're deliberately not doing that — it's where the danger lives. Thaw is: restore a warm, coherent machine in milliseconds, then start a clean process on it. The speed of a snapshot with the safety of a cold boot.

What we measured

Here's the part that matters. We ran a real Node HTTP app through the full lifecycle on production — deploy, idle, the seed bake on first sleep, delete the sandbox, then a request to wake it — and measured the wake end to end.

THAW WAKE  (real Node app, production, kernel 6.17)
  wall time:   164 ms
  boot_mode:   snapshot-natid          # a restore, not a boot
  boot_ms:     123
  app says:    THAW_OK marker=<survived>  who=<rotated env>  pid=<new>
  ext4 errors: 0

Every property we designed for showed up in that one HTTP response:

164 ms wall — confirmed a restore by the boot mode, not a cold boot.
A marker we'd written to disk before the bake survived the delete-and-restore — proof the restore landed on the seed's own coherent disk.
A new process ID — fresh process, not a resurrected one.
The environment was the rotated value applied at wake, not the stale one frozen at deploy.
Zero ext4 errors — the incident class that haunted the first attempt is, this time, structurally absent.

From 54 seconds to 164 milliseconds. That's not an optimization; it's a different mechanism. The 54-second path built a machine. The 164ms path unfroze one.

"But it's distributed" — the part that almost broke it

Our first end-to-end test on the real fleet… didn't thaw. It cold-booted in ~15s. Confusing, because the mechanism clearly worked in isolation.

The reason: a seed is ~13 GB, so the first version kept it local to the node that baked it. But a request can wake an app on any node. If the scheduler placed the wake on a different node than the one holding the seed — which, with load-spreading, is most of the time — there was no seed there, so it fell back to the cold-boot path.

The fix was to replicate the seed through object storage: on bake, upload it; on a wake that lands on a seed-less node, pull it before restoring. The nice surprise was the size. A 13 GB seed is mostly a 10 GB rootfs that's mostly zeros, so a sparse tar + zstd compresses it down hard:

seed.tar.zst in object storage:  756,451,291 bytes  →  721 MiB   (~18× smaller)

So the storage math is far gentler than the on-disk 13 GB suggests — and it's per app, not per deploy (a new deploy invalidates and purges the old seed, since a seed that froze old code is worthless). 10,000 hibernated apps is on the order of ~7 TB of object storage, not the hundreds of TB the raw number implies. A node-local LRU cap keeps each box's working set bounded; object storage is the durable backstop, with a TTL to reap genuinely abandoned seeds.

After replication landed, a cross-host wake thawed cleanly (boot_mode=snapshot-natid, boot_ms=68) — the seed pulled from storage, then restored. Every wake thaws now, regardless of which node it lands on.

Why this is even possible

Thaw isn't a clever trick layered on top of containers. It falls out of the substrate.

A container can't be frozen to a coherent file and thawed — it shares the host kernel, so there's no self-contained machine state to snapshot. A Firecracker microVM is a complete machine: its own guest kernel, its own memory, its own virtual disk. That's exactly what makes it freezable. The same property that gives a microVM stronger isolation than a container is the property that lets it cold-restore in milliseconds.

You don't get Thaw on a substrate that was never a real machine in the first place.

Thaw vs. "stay warm"

It's worth being precise about how this compares to the popular alternative — keeping an instance warm (Vercel's Fluid compute is the most polished version; their docs describe pre-warming, bytecode caching, and sharing one instance across concurrent invocations, billed on active CPU).

That approach is genuinely good: under steady traffic you essentially never hit a cold start, because the instance is already there. It works to avoid the cold start.

Thaw bets on the substrate instead. Because a microVM freezes to a file and thaws in milliseconds, we don't keep anything warm to hide the cold start — we make the cold start cheap enough to stop hiding it. The sandbox is deleted while idle, so there's nothing to run or bill. It shines for the long tail: previews, side projects, agent sandboxes — the things that are idle most of the time and need to be instant the moment someone shows up.

One works to avoid the cold start. The other makes the cold start fast — and goes all the way to zero.

The honest footnotes

The very first wake after each deploy still takes the cold-boot path (no seed baked yet); every wake after the first idle is the sub-second thaw.
A cross-host first wake pays a one-time seed pull from object storage (seconds) before it thaws; that node then has it cached.
We deliberately don't resurrect in-flight state. "Thaw" is a fast warm machine + a fresh process, not time travel.

That's it. A frozen microVM, thawed back in about the time it took you to read this sentence. We call it Thaw.

Addiction of AI

Ajay Kumar — Tue, 19 May 2026 12:41:55 +0000

In the past 5 months, I have created 4 complex projects, but I still keep thinking about how I can create more and what else I can build, because AI can now do so many things. Every new idea feels possible. Instead of slowing down after finishing one project, I immediately move to the next challenge.

Sometimes it feels less like motivation and more like an addiction to creating. AI has removed many traditional barriers, so the limit is no longer technical skill alone — it’s imagination, execution, and focus. The more I build, the more opportunities I see around me.

So far I have:

PandaStack — Deploy Everything, Everywhere

Deploy static sites, containers, databases, cron jobs, and edge functions — all from GitHub. PandaStack is the all-in-one cloud platform for developers.

pandastack.io

Sandflare — The runtime for AI agents · by Pandastack

Give your coding agents a real Linux environment — ready in under 1 seconds.

sandflare.io

Autonomous SEO Engine | GrowDeck

GrowDeck is an autonomous SEO engine that crawls your site, generates landing pages, and deploys them automatically.

growdeck.ai

pandastack-io / pandaflow

Open source AI agent visual workflow builder. Build, connect, and run AI agents with 160+ nodes. Powered by Sandflare.io isolated microVM execution.

PandaFlow

Open source AI agent visual workflow builder by PandastackIO Inc.

Build, deploy, and orchestrate AI agents visually. Connect LLMs, databases, APIs, and code execution nodes on a drag-and-drop canvas. Powered by Sandflare.io isolated microVM execution.

Features

🎨 Visual Workflow Builder — Drag-and-drop canvas powered by React Flow
⚡ Isolated Code Execution — Run Python, Node.js, Go, and Bash in Sandflare microVMs with browser automation support
🤖 160+ Nodes — LLMs, databases, APIs, webhooks, transformations, and more
🔄 Real-time Monitoring — Live execution tracking via Server-Sent Events
🔐 Secrets Management — Encrypted per-organization secret store
📋 Templates — Pre-built multi-node workflow templates to get started fast
🔌 Extensible — Add custom nodes by extending the node registry

Tech Stack

Layer	Technology
Frontend	Next.js 16, React 19, TypeScript, Tailwind CSS, shadcn/ui, React Flow
Backend	Next.js API Routes, Drizzle ORM
Database	PostgreSQL 16
Cache	Redis 7
Execution	Sandflare microVMs (browser-agent +

…

View on GitHub

lets roast your website

Ajay Kumar — Thu, 14 May 2026 09:49:53 +0000

Lets roast your website and put your score in comments

Roast My SEO 🔥 - Free AI-Powered SEO Analysis | GrowDeck | GrowDeck

Your SEO probably sucks. Get brutally honest feedback powered by AI. Free, instant results.

growdeck.ai

I built an open-source visual AI agent builder — PandaFlow

Ajay Kumar — Mon, 11 May 2026 11:29:58 +0000

If you've ever tried to wire up an AI agent — connecting an LLM to a database, a webhook, some Python code, and an API — you know how fast it becomes spaghetti.

That's why I built PandaFlow (https://github.com/pandastack-io/pandaflow) — an open-source, drag-and-drop visual workflow builder for AI agents.

What it does

You connect nodes on a canvas. Each node can be:

An LLM call (GPT, Claude, etc.)
Python / Node.js / Go / Bash code — running in isolated microVMs
A database query, API call, or webhook trigger
A transformation, condition, or template

160+ nodes out of the box. Real-time execution monitoring via SSE. Encrypted secrets per org.

The stack

Next.js 16 · React 19 · TypeScript · Drizzle ORM · PostgreSQL · Redis · React Flow · NextAuth v5

Code runs in Sandflare.io (https://sandflare.io) microVMs — fully isolated, no shared runtimes.

Run it locally in 5 commands

git clone https://github.com/pandastack-io/pandaflow.git
cd pandaflow
npm install
cp .env.example .env.local   # set SANDFLARE_API_KEY=mock-api-key for local dev
npm run db:migrate && npm run dev

Open http://localhost:3000 — done. No cloud account needed.

Why open source?

Because AI agent tooling shouldn't be locked behind a SaaS paywall. PandaFlow is MIT licensed — self-host it, fork it, extend it.

⭐ If this is useful to you, a star on GitHub goes a long way: github.com/pandastack-io/pandaflow (https://github.com/pandastack-io/pandaflow)

Contributions, issues, and ideas very welcome!

What is an AI Agent Runtime?

Ajay Kumar — Mon, 20 Apr 2026 11:00:28 +0000

An AI Agent Runtime is the execution layer that bridges an LLM's decisions and real-world computation — providing isolated environments, tool execution, state management, and I/O handling so agents can act safely at scale.

sandflare.io - AI Agent Sandboxes with 🧠

Ajay Kumar — Tue, 14 Apr 2026 04:45:27 +0000

AI agents are getting more powerful.

They can write code, browse the web, install dependencies, and automate workflows. But there's still one major problem:

Where should these agents actually run?

Most teams today either:

Run code directly on their servers (unsafe)
Use containers (slow to start, hard to manage)
Use ephemeral sandboxes (lose context every time)

None of these are ideal for AI agents.

So we built Sandflare.

👉 https://sandflare.io

I built a sandbox that boots an AI agent VM in ~300ms — here's how

Ajay Kumar — Tue, 31 Mar 2026 06:05:25 +0000

If you've ever built an AI agent that runs code, you've hit the same wall I did:
how do you run untrusted LLM-generated code safely, without it taking forever?

I tried Docker. Shared kernel — felt too risky for arbitrary code execution. I tried full VMs. Safe, but 5–10 second cold starts killed the UX.

So I built Sandflare — it uses Firecracker microVMs to launch isolated sandboxes in ~1-2s. Tweaked it further and its ~300ms now. Sandflare psql also launches in milliseconds. How wonderful is that.

How we get to ~300ms

The trick is snapshot + restore with userfaultfd (UFFD).

Boot a VM once, fully configured
Take a memory snapshot
On every new sandbox request, restore from that snapshot
Memory pages fault in on-demand — the VM is responsive before it's fully loaded into RAM

This is the same technique AWS uses internally. The result: consistent sub-400ms cold starts.

What Sandflare actually does

Beyond fast boots, I added the things I kept needing for agent workloads:

Run code and stream output:

from sandflare import Sandbox

sb = Sandbox.create("agent", size="nano")

for event in sb.stream("python3 analyse.py"):
    if event.event == "stdout":
        print(event.line)

Wire a Postgres database in one call:

from sandflare import Sandbox, Database

db = Database.create("memory", password="Secret#42")
sb = Sandbox.create("agent")
sb.wire(db.name)

# DATABASE_URL is now injected into the sandbox env
# your agent can just connect normally

Upload files, download results:

sb.upload(csv_bytes, "/home/agent/data.csv")
chart = sb.download("/home/agent/chart.png")

Real benchmark numbers

Running from a GCP worker in the same region:

run 1: 363ms
run 2: 292ms
run 3: 307ms
run 4: 303ms
run 5: 345ms

min:  292ms  |  mean: 322ms  |  p50: 307ms

Who is this for?

Coding agents — give Claude/GPT a real sandbox to write and run code
AI data analysis — upload a CSV, run pandas, download the chart
CI/CD pipelines — clean isolated environment per run
Multi-agent pipelines — multiple sandboxes sharing one Postgres DB

Try it

Free tier: 10 sandboxes, no credit card.

👉 sandflare.io

📖 docs.sandflare.io

Would love to hear how you're handling code execution in your agent projects — and if anyone has pushed Firecracker cold starts below 200ms, I'm all ears!

I’m Trying to Build a Simple Ecosystem for Developers

Ajay Kumar — Tue, 10 Mar 2026 12:02:40 +0000

I’m Trying to Build a Simple Ecosystem for Developers

Over the past few years I noticed something frustrating while building and managing applications.

Every part of the developer workflow lives on a different platform.

You might build your app using one tool, deploy it somewhere else, and monitor uptime using a completely different service.

A typical stack ends up looking like this:

one platform for building
one for deployments
one for databases
one for monitoring
several dashboards to manage everything

It works, but it's fragmented. So I started working on something simpler.

I’m trying to create a small ecosystem of developer tools that work together across the entire lifecycle of an application.

The idea is simple: Build → Deploy → Monitor

Here’s what that ecosystem currently looks like.

1. Build Applications with AI

👉 https://pandastack.ai

https://pandastack.ai focuses on helping developers generate applications using AI. Its in preview phase. I used sandboxes for them and users can build frontend and backend both apps.

2. Deploy Applications and Services

👉 https://pandastack.io

pandastack.io is the deployment platform.

Developers can deploy:

backend APIs
full-stack applications
Docker containers
databases
managed services

You can connect a GitHub repository and deploy directly, or deploy containers and services manually.

The goal is to provide deployment infrastructure without unnecessary complexity.

3. Monitor Uptime

👉 https://pandawatch.io

Once applications are live, monitoring becomes essential.

pandawatch.io is focused on uptime monitoring and reliability checks.

Developers can monitor their services and detect downtime quickly.

Features include:

uptime checks
status tracking
downtime alerts

The Workflow

Together, the tools create a simple developer pipeline:

pandastack.ai → pandastack.io → pandawatch.io

Why I'm Building This

I’m not trying to replace every tool developers already use.

The goal is simply to make the common workflow of building and running applications easier.

Instead of stitching together multiple services, developers can move through the lifecycle with fewer moving parts.

I’d Love Feedback

This ecosystem is still evolving, and feedback from developers is extremely helpful.

If you'd like to explore it:

Build apps with AI → https://pandastack.ai
Deploy applications → https://pandastack.io
Monitor uptime → https://pandawatch.io

Let me know what you think or what you would improve.