Forem: MOHIT BHAT

Building a Web3 Camera That Proves Photos Are Real, Powered by Gemini CLI

MOHIT BHAT — Thu, 05 Mar 2026 08:53:04 +0000

This is a submission for the Built with Google Gemini: Writing Challenge

What I Built with Google Gemini

So I built this thing called LensMint. It's a physical Web3 camera that solves something I've been thinking about for a while: in a world full of AI-generated images, how do you actually prove a photo is real?

The concept is pretty simple, but building it was honestly a wild ride. Picture a Raspberry Pi 4 with a camera module strapped to it, a little touchscreen display, and a whole lot of cryptography running underneath. You snap a photo, and the camera cryptographically signs it with a key that's literally derived from the hardware itself. Then it uploads to Filecoin for permanent storage, mints an ERC-1155 NFT on Ethereum, kicks off a zero-knowledge proof to verify authenticity on-chain, and throws a QR code on screen so anyone nearby can claim their own edition. All of that happens in seconds, right there on the device.

Now here's the thing. This project ended up being around 7,000+ lines of code across Python, JavaScript, Solidity, and bash scripts. Hardware stuff, blockchain contracts, ZK proof pipelines, decentralized storage, a full-stack web app. That's a LOT of ground to cover for one person.

The reason I was able to actually ship it? Google Gemini CLI. It became my constant companion throughout this build. Not just for generating code, but for thinking through architecture, debugging weird errors at 2am, and navigating SDKs I'd never touched before. Let me walk you through the whole thing.

Demo

GitHub Repository: lensmint-camera-gemini
Video Demo: Watch on YouTube

🔧 Hardware Components

💻 Backend Screenshots

📷 Physical Camera Final Images

The Problem LensMint Solves

Think about this for a second. Right now, anyone can fire up Midjourney or DALL-E and generate a photorealistic image of basically anything. That's cool for art, but it's a nightmare for trust. A photojournalist captures something incredible in the field, and people ask "is that even real?" A photographer tries to license their work, and clients wonder if AI made it. Event organizers have no reliable way to prove who actually showed up.

This bugged me enough to build something about it. LensMint attacks it from four angles:

Proof of Authenticity. Every photo is signed by a cryptographic key that's derived from the physical hardware itself (the CPU serial number, MAC address, camera sensor properties, and a persisted salt). The signature proves which exact device captured the image. This isn't software that can be spoofed. The key is deterministic to the hardware.

Permanent Storage. Photos go straight to Filecoin via the Synapse SDK. Not a cloud server. Not someone's S3 bucket. Decentralized, permanent storage that nobody can take down.

On-Chain Verification. Every photo becomes an ERC-1155 NFT. The device must be registered in our DeviceRegistry smart contract before it can mint. Then vlayer generates a TLS-notarized web proof of the metadata, compresses it into a RISC Zero zero-knowledge proof, and submits it on-chain for verification. The blockchain confirms the photo is real without revealing any private data.

Easy Distribution. After capturing a photo, the camera shows a QR code. Anyone nearby can scan it, enter their wallet address on a clean web page, and receive an edition NFT. No wallet setup on the camera. No complicated flows. Scan, paste, done.

The Architecture, Briefly

LensMint has five main components that all talk to each other:

The Camera App is a Python/Kivy application running on the Raspberry Pi. It handles the live camera preview, photo capture, image signing, and QR code display. The identity system generates a SECP256k1 ECDSA keypair from hardware identifiers. When you capture a photo, it computes a SHA-256 hash and signs it with the device's private key.

The Hardware Web3 Service is a Node.js/Express backend also running on the Pi. It receives captured images from the camera app, uploads them to Filecoin, creates claims on the public server, mints NFTs by calling the smart contracts, and orchestrates the entire ZK proof pipeline. It also polls for pending edition requests and mints them automatically.

Smart Contracts on Ethereum Sepolia include the DeviceRegistry (which tracks authorized cameras), the LensMintERC1155 (which handles NFT minting with full provenance metadata), and the LensMintVerifier (which validates RISC Zero ZK proofs on-chain).

The Public Claim Server runs on Render and serves the claim pages. When someone scans the QR code, they land on a page with an animated NFT card preview where they can enter their wallet address.

The Owner Portal is a React/Vite web app with Privy wallet integration for device owners to manage their cameras and gallery.

Raspberry Pi 4 (Camera + Touchscreen)
    │
    ├── Camera App (Python/Kivy)
    │     └── Hardware Identity (SECP256k1 keys from hardware)
    │
    └── Web3 Service (Node.js)
          ├── Filecoin (Synapse SDK for permanent storage)
          ├── Ethereum Sepolia (Smart contracts)
          │     ├── DeviceRegistry.sol
          │     ├── LensMintERC1155.sol
          │     └── LensMintVerifier.sol (RISC Zero)
          ├── vlayer (ZK proof generation)
          └── Public Claim Server (Render)
                └── Owner Portal (React/Vite + Privy)

How Gemini CLI Powered the Entire Build

Okay, this is the part I'm most excited to talk about because honestly, without Gemini CLI, I don't think this project would exist.

Building LensMint meant juggling at least five completely different technology domains at the same time. I2C battery monitoring and camera modules on a Raspberry Pi. Python GUI development with Kivy. Solidity smart contracts. Zero-knowledge proof pipelines (which I'd never touched before). Full-stack web development with React and Express. Any one of these could be its own project. I was trying to do all of them at once.

Gemini CLI is what made that possible. Let me break down what it is, how it actually works, and then show you what it looked like in practice.

What Is Google Gemini?

Before I get into the CLI specifically, let me talk about Gemini itself because understanding the model helps you use the tool better.

Google Gemini is Google's family of multimodal AI models. When people say "Gemini," they're talking about large language models built by Google DeepMind that can understand and generate text, code, images, audio, and video. The model family includes different sizes: Gemini Ultra for the most complex tasks, Gemini Pro for balanced performance, and Gemini Flash for speed-optimized workloads.

What makes Gemini interesting for developers specifically is a few things:

Massive context window. Gemini models support context windows up to 1 million tokens (and Gemini 2.5 Pro pushes even further). For coding, this is huge. It means the model can hold your entire codebase in its working memory and reason about relationships between files that are thousands of lines apart. When I was working on the connection between my Python camera app and my Node.js backend, Gemini could see both codebases simultaneously.

Native code understanding. Gemini was trained on enormous amounts of code across many languages. It doesn't just pattern-match syntax. It understands data flow, error handling patterns, security implications, and architectural trade-offs. When I asked it about my Solidity access control patterns, it caught a reentrancy issue that I had totally missed.

Multimodal capabilities. While I primarily used the text/code capabilities, Gemini can also reason about images, which is relevant for a camera project. The model's ability to understand visual context alongside code context opens up interesting possibilities.

Function calling and tool use. Gemini models can interact with external tools, APIs, and your local environment. This is what makes the CLI integration so powerful. It's not just answering questions in isolation. It can read files, understand project structure, and ground its responses in your actual code.

What Is Gemini CLI?

Gemini CLI is Google's open-source command-line tool that brings all of Gemini's capabilities directly into your terminal. Think of it as having a senior developer sitting next to you who can instantly read any file in your project, understand how everything connects, and help you write, debug, or refactor code.

Here's what makes it different from just chatting with Gemini in a browser:

It lives in your project. When you run gemini in your project directory, it automatically understands your file structure, your dependencies, your existing patterns. You don't have to copy-paste code into a chat window and explain what everything does. It already knows.

It remembers context across turns. You can have a multi-turn conversation where you start by discussing architecture, move into implementation, hit a bug, debug it, and then continue building. Gemini CLI holds the thread of the entire conversation. This was essential for LensMint because I'd often start with "I need a module that does X," get a first draft, test it, hit an error, paste the error back in, and iterate until it worked.

It can read and reference your files. You can say "look at my web3Service.js and create a similar service for vlayer" and it will actually read that file, understand the patterns, and produce code that follows the same conventions. This consistency across a codebase matters way more than people think.

Getting started is dead simple. You install it, authenticate with your Google account, and you're ready. No complex configuration. No API key management headaches. Just npm install -g @anthropic/gemini-cli (or however Google distributes it), authenticate, and go.

The capabilities I leaned on the most:

Code generation that fits your project. When I asked Gemini CLI to create my vlayerService.js module, it had already seen my web3Service.js and filecoinService.js. The generated code followed the same error handling patterns, the same logging style, the same module structure. I didn't have to explain any of that. It just picked it up.

Cross-language reasoning. LensMint has Python talking to Node.js talking to Solidity. I could say something like "the Python hardware identity module exports the private key to a file, and the Node.js service needs to read it, what's the cleanest way to bridge this?" and Gemini CLI gave me a solution that understood both ecosystems properly. The getHardwareKey.js bridge module came directly from that kind of conversation.

Debugging with real stack traces. When stuff broke (and oh man, stuff broke a lot), I'd paste the error right into Gemini CLI and get back debugging advice that referenced my actual file names and function signatures. Not generic "check your imports" advice. Real, contextual diagnosis.

Architecture thinking. Some of my most valuable Gemini CLI sessions were before I wrote any code at all. I'd describe what I wanted to build and explore different approaches. Should the camera app talk directly to the blockchain? Should there be a backend service in between? How should the claim system work? These conversations saved me from going down dead ends.

Concrete Examples from the Build

Alright, theory is nice, but let me show you specific moments where Gemini CLI saved my skin.

The Hardware Identity System. Generating a deterministic ECDSA keypair from hardware identifiers sounds simple enough on paper. In practice? A dozen edge cases I hadn't thought about. What if someone swaps the camera module? What if wlan0 isn't available on that particular Pi? How do you persist the salt safely so the key survives reboots? I brought all these questions to Gemini CLI and we worked through the fallback chain together: try /proc/cpuinfo for CPU serial, fall back to a default. Try wlan0 MAC address, then eth0, then a placeholder. Store the salt at /boot/.device_salt with restricted permissions, keep a backup at ~/.lensmint/.device_salt_backup. That kind of careful defensive programming came directly from iterating with Gemini. I wouldn't have thought of half those fallback scenarios on my own.

Solidity Contract Design. The interaction between DeviceRegistry, LensMintERC1155, and LensMintVerifier required careful design. The ERC1155 contract needs to verify that the caller is a registered and active device before allowing minting. The Verifier contract needs to validate RISC Zero proofs against expected parameters (notary fingerprint, URL pattern, queries hash). Gemini CLI helped me design the access control patterns and the data structures for storing provenance metadata on-chain. It also caught a reentrancy issue I'd missed in an early draft of the mintEdition function.

The ZK Proof Pipeline. This was the most complex part of the build. The flow goes: call the vlayer Web Prover API to create a TLS-notarized web proof of the metadata endpoint, then send that to the ZK Prover API for RISC Zero compression, extract specific fields using JMESPath queries, and finally submit the proof on-chain. Gemini CLI helped me understand vlayer's API structure (which was new to me), design the extraction queries, handle the async proof generation flow, and troubleshoot proof validation failures on-chain.

Kivy UI on a Small Screen. Building a camera interface for a 3.5-inch touchscreen is surprisingly tricky. Everything needs to be touch-friendly with large buttons. The live preview needs to run at 30 FPS without blocking the UI thread. Gemini CLI helped me structure the Kivy layout, implement the texture-based camera preview (using Clock.schedule_interval for frame updates), and design the gallery view with thumbnail grids. It also helped me figure out the correct approach for overlaying QR codes on the live preview without disrupting the camera feed.

Bridging Python and Node.js. The camera app exports the device private key so the Node.js backend can use it for blockchain transactions. This required a careful bridge: the Python side writes the key to a .device_key_export file, and the Node.js side reads it with multiple fallback strategies (read file, run Python export script, or execute inline Python). Gemini CLI helped me design this bridge robustly with proper error handling and caching (the key is cached for one hour to avoid repeated file reads or Python process spawning).

The Development Workflow

My daily rhythm with Gemini CLI settled into something like this:

Think out loud. I'd describe what I needed in plain English ("I need a service that uploads images to Filecoin using the Synapse SDK, handles payment setup, and returns PieceCIDs") and Gemini would help me think through the interface, the error cases, and how it should connect to everything else.
Get a first draft. Gemini CLI would produce a working scaffold. Because it could see my other files, the code already felt like it belonged in the project.
Break things, fix things. I'd test, hit errors, paste the stack trace back into Gemini CLI, get a fix, test again. This loop was incredibly fast because Gemini already understood the full context.
Wire things together. When connecting components across languages, Gemini CLI helped me keep data formats, API contracts, and error handling consistent. It would flag things like "hey, your Python side sends image_hash but your Express endpoint expects imageHash" before those bugs ever hit runtime.
Stress test mentally. Gemini CLI was great at playing devil's advocate. "What happens if the Filecoin upload succeeds but the NFT mint fails? What if the user scans the QR code after the claim expires? What if the device wallet doesn't have enough ETH for gas?" These questions led to retry logic, error recovery, and UX improvements I wouldn't have thought to add.

Tips and Tricks for Getting the Most Out of Gemini CLI

After spending weeks with Gemini CLI on this project, I picked up some patterns that made a real difference. If you're about to start using it, these might save you some time.

1. Always Start From Your Project Root

This sounds obvious but it matters. When you launch Gemini CLI from your project's root directory, it can traverse your file tree and understand how things connect. If you launch it from some random directory, you lose all that context. I always cd into lensmint-camera/ before starting a session.

2. Give It the Big Picture First

Before diving into code, spend your first prompt explaining what the project does. Something like "This is a Web3 camera built on Raspberry Pi. It captures photos, signs them cryptographically, uploads to Filecoin, and mints NFTs on Ethereum. I'm about to work on the ZK proof pipeline." This framing helps Gemini give you much better answers for the rest of the conversation because it understands where each piece fits.

3. Reference Your Existing Files Explicitly

Instead of describing your code patterns from scratch, just point Gemini at an existing file. "Look at how I structured filecoinService.js and create a similar service for vlayer integration" produces way better results than "create a vlayer service with good error handling." It mirrors your actual style.

4. Use It for Architecture Decisions Early

Some of my highest-value Gemini CLI sessions produced zero code. I'd explain what I wanted to build and ask it to help me think through trade-offs. "Should the camera app call the blockchain directly via Python, or should I put a Node.js service in between?" The answer (use Node.js because ethers.js is way more mature than Python's web3 libraries for what I needed) saved me from a painful refactor later.

5. Keep Conversations Focused

I learned this the hard way. Don't try to solve everything in one massive conversation. If you're debugging a Filecoin upload issue, don't suddenly switch to asking about your Solidity contracts. Start a new session. Gemini CLI holds context within a conversation, but keeping topics focused gets you better answers.

6. Paste Full Error Messages, Not Summaries

When debugging, paste the complete stack trace. Don't paraphrase it. Don't say "I'm getting a timeout error." Paste the actual error with line numbers, file paths, all of it. Gemini CLI can trace through your code to find root causes, but only if it has the full picture.

7. Ask It to Review, Not Just Generate

One underused workflow: write your code yourself, then ask Gemini CLI to review it. "Here's my mintEdition function in Solidity. Can you spot any issues?" It caught a reentrancy vulnerability in my contract that I'd completely missed. Code review is where it really shines because it brings a fresh perspective to code you've been staring at for hours.

8. Use It to Learn New SDKs

Whenever I hit a new SDK (Filecoin Synapse, vlayer, Privy), my first move was to describe what I wanted to accomplish and ask Gemini CLI for an implementation. Even if the generated code wasn't perfectly up to date with the latest API, it gave me the right mental model and structure. I'd then adjust the specifics by checking the official docs. It's way faster than reading docs cold.

9. Ask "What Could Go Wrong?"

After implementing a feature, I'd ask Gemini CLI something like "what are the failure modes for this upload flow?" The answers were consistently useful. It would remind me about network timeouts, partial failures, race conditions, and edge cases that only show up in production. A lot of LensMint's retry logic and error recovery exists because of these conversations.

How It Looks in Action

The physical camera is a Raspberry Pi 4 in a custom enclosure with a touchscreen showing the live camera preview. When you press the capture button:

The screen briefly flashes to confirm capture
The image is signed, uploaded, and minted (status indicators show each step)
A QR code appears on screen
Anyone nearby scans the QR code on their phone
They see a claim page with an animated preview of the NFT
They enter their wallet address and receive an edition NFT

The entire flow from capture to QR code display takes about 10 to 15 seconds. Edition minting after someone submits their wallet address takes another 15 to 30 seconds depending on network conditions.

What I Learned

ZK proofs aren't as scary as they look. I'll be honest, I went into this project pretty intimidated by zero-knowledge proofs. The math papers are intense. But vlayer's Web Prover and ZK Prover APIs abstract most of that away. You're basically telling it "prove that this server actually returned this data" and "compress that proof for on-chain verification." The hard part was getting the JMESPath extraction queries right and understanding the journal data format the verifier contract expects. Once that clicked, the ZK pipeline became just another API call. If you've been avoiding ZK proofs because they seem too complex, give them a shot. The tooling has gotten really good.

Hardware identity is an underappreciated idea. Having a device generate its own deterministic crypto identity from its physical components is elegant in a way that surprised me. The Raspberry Pi literally IS its own Ethereum wallet. No seed phrases. No key files to back up (well, just the salt). Same hardware, same keys, every time. I keep thinking about where else this pattern could work. IoT devices, supply chain tracking, sensor networks. Anytime you need to prove which physical device did something.

Bridging languages is harder than it sounds. Getting Python and Node.js to play nice on the same Pi took way more thought than I expected. File-based IPC, spawning subprocesses, caching keys, handling errors that cross language boundaries. These problems don't show up in tutorials but they dominate real-world systems. If your project spans multiple languages, budget extra time for the glue code.

Small screens force good design. Building for a 3.5-inch touchscreen means you literally cannot have a complex UI. Every screen gets one job. The camera preview is full-screen with tiny overlays. The QR code is big and centered. The gallery is a simple grid. Having that constraint actually made the UX way better than if I'd had a big screen to fill.

Gemini CLI compresses the learning curve. Before Gemini CLI, running into an unfamiliar SDK meant hours of reading docs, searching for examples, and trial-and-error. With it, I could describe what I needed, get a working implementation, and iterate from there. It doesn't eliminate the learning. You still need to understand what you're doing. But it compresses the time dramatically. Filecoin integration that would have taken a full day took a couple of hours.

Google Gemini Feedback

What Worked Really Well

Cross-language understanding is best in class. I could discuss Python, JavaScript, and Solidity in the same conversation, and Gemini CLI tracked the data flow across all three. When I said "the Python module signs the image hash and sends it to the Express endpoint, which then passes it to the Solidity contract's mintOriginal function," it understood the entire chain and could spot inconsistencies I'd missed. That kind of cross-language reasoning saved me hours of debugging integration issues.

It learns your style. Gemini CLI's ability to read my project files and understand my existing patterns meant the code it generated actually felt like mine. It picked up my logging conventions, my error handling style, how I organize modules. This matters more than people realize. When you come back to maintain the code six months later, you don't want half the codebase in one style and half in another.

Debugging is a superpower. Pasting a stack trace and getting back a diagnosis that references my specific file names, variables, and function signatures is night and day compared to generic debugging advice. Multiple times it identified root causes that I'm pretty sure would have cost me hours to find on my own.

Architecture brainstorming is maybe the highest ROI use case. The conversations I had before writing code might have been the most valuable of all. Gemini CLI talked me out of doing blockchain calls directly from Python and into building a separate Node.js service instead. That turned out to be exactly the right call because ethers.js is significantly more mature than Python's web3 options for what I needed.

Where It Struggled

I want to be honest here because I think balanced feedback is more useful than hype.

Brand new SDKs are hit or miss. The Filecoin Synapse SDK was pretty new when I was building, and Gemini CLI sometimes generated code with outdated API signatures. Totally understandable since training data has a cutoff. I just had to cross-reference with the actual SDK source code and docs in those cases. Not a dealbreaker, but worth knowing about.

Raspberry Pi weirdness. Some things are just... Pi-specific. Picamera2's quirks with different camera module versions, I2C communication edge cases with the UPS HAT, display driver issues. Gemini CLI gave reasonable approximations but couldn't always nail the Pi-specific details. I ended up writing a fix_picamera2.sh script for installation edge cases that no AI could fully predict.

Very long sessions can drift. In marathon debugging sessions (20+ back and forth exchanges), I occasionally noticed earlier context fading. My workaround was simple: start a new conversation with a fresh summary of where I was. Splitting conversations by component (one for the camera app, one for the blockchain stuff, one for the ZK pipeline) worked better than one giant thread.

The Bottom Line

Gemini CLI genuinely changed the speed at which I could build this project. LensMint touches hardware, cryptography, blockchain, decentralized storage, zero-knowledge proofs, and full-stack web dev. That's an absurd amount of ground for one developer. Without Gemini CLI holding context across all those domains simultaneously, this project would have taken months. It took weeks.

It's not magic. I want to be clear about that. You still need to understand what you're building. You still need to review every line of generated code. You still hit edge cases that you have to solve yourself. But it compresses the distance between having an idea and having working code to a degree that genuinely surprised me.

If you're working on something ambitious, especially if it crosses multiple tech domains like LensMint does, give Gemini CLI a real shot. Open your terminal, point it at your project, and start talking to it like you'd talk to a teammate. You might be surprised how far you get in an afternoon.

Cloudgen Cloud Platform: Deploy Your App by Talking to It, Built with GitHub Copilot CLI

MOHIT BHAT — Sun, 15 Feb 2026 17:50:41 +0000

This is a submission for the GitHub Copilot CLI Challenge.

What I Built

Cloudgen is a product that turns cloud deployment into a conversation. You describe what you need in plain English, your app, how many users you expect, whether you need a database or cache, and an AI figures out the rest. No config files, no dashboards, no wrestling with infrastructure. You get a clear plan, a cost estimate, and you’re one approval away from your app being live.

Behind that simple experience is a lot of complexity. Understanding your intent, analyzing your repo, sizing resources, generating a safe execution plan, and then actually provisioning everything and giving you live URLs and connection strings. We built Cloudgen so you never have to touch that complexity yourself.

Demo

Live project: https://cloudgenapp.vercel.app/

Video walkthrough: https://www.loom.com/share/0b5f73a623bb438ebd1ec41053427c21

GitHub Repository: https://github.com/mbcse/cloudgen

📌 The Problem

Deploying even a simple application to the cloud today requires:

Writing Dockerfiles, YAML manifests, and IaC templates
Navigating complex dashboards across AWS / GCP / Azure
Manually provisioning databases, caches, compute, and networking
Understanding container orchestration, port mappings, reverse proxies, and health checks

For a developer who just wants to ship their app, this is too much friction.

Small teams and indie developers often spend more time wrangling infrastructure than building product. The gap between "I have a repo" and "it's live on the internet" shouldn't require DevOps expertise.

💡 Our Solution

Cloudgen is a chat-first cloud control plane where users describe their infrastructure needs in plain English, and an agentic AI pipeline analyzes their repository, generates a deployment plan, and provisions real infrastructure — all with human-in-the-loop approval.

"Deploy my Next.js app from GitHub with a Postgres database for 500 users"

→ Cloudgen analyzes the repo, generates a resource plan with cost estimates, and after approval, provisions containers, databases, and networking automatically.

Why it matters

Getting from “I have a repo” to “it’s live on the internet” usually means learning orchestration, networking, databases, and billing. Small teams and indie devs end up spending more time on infra than on product. Cloudgen flips that. You say what you want, review a plan the AI proposes, approve it, and we handle the rest. Deployment becomes something you do in a chat, not a checklist of manual steps.

✨ Product Features

Feature	Description
🗣️ Chat-to-Deploy	Natural language interface, describe what you need, get a deployment plan
🔍 Smart Repo Analysis	Auto-detects runtime (Node.js/Python), framework, build commands, and Dockerfile presence
📋 Plan Review & Approval	Every deployment requires explicit human approval, see resources, rationale, cost estimates, and YAML steps before anything runs
🐳 Multi-Resource Provisioning	Deploy App Services, Compute Instances, PostgreSQL, and Redis from a single conversation
💰 Cost Estimation	AI-powered resource sizing with tiered pricing (`ac.starter`, `ac.pro`, `ac.business`)
📡 Live Deployment Logs	Real-time streaming logs as containers build and start
🔗 Endpoint Discovery	Automatically returns live URLs and connection strings after deployment
🧠 RAG-Powered Context	Internal docs and repo READMEs are indexed for smarter, context-aware responses
⚡ Graceful Degradation	Works without an LLM API key using deterministic heuristic fallbacks

🏗️ Architecture Overview

┌─────────────────────────────────────────────────────────────────┐
│                        Next.js Frontend                         │
│   Dashboard  ·  Chat UI  ·  Plan Review  ·  Deployment Logs    │
└──────────────────────────────┬──────────────────────────────────┘
                               │ REST API
┌──────────────────────────────▼──────────────────────────────────┐
│                     Fastify API Server                          │
│                                                                 │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │               LangGraph Chat Orchestrator                │   │
│  │                                                          │   │
│  │   Parse Intent ──► RAG Retrieval ──► Plan Generation     │   │
│  │        │                                    │            │   │
│  │        ▼                                    ▼            │   │
│  │   ┌─────────┐   ┌──────────────┐   ┌────────────┐       │   │
│  │   │ Intent  │   │    Repo      │   │  Capacity  │       │   │
│  │   │ Agent   │   │  Inspector   │   │   Agent    │       │   │
│  │   │         │   │    Agent     │   │            │       │   │
│  │   └─────────┘   └──────────────┘   └────────────┘       │   │
│  │        Gemini 2.0 Flash  /  Deterministic Fallback       │   │
│  └──────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────┐   │
│  │   Deployer   │  │  RAG Engine  │  │   Prisma + Postgres  │   │
│  │  (SSH + Docker)│  │  (pgvector)  │  │   (Control Plane DB) │   │
│  └──────┬───────┘  └──────────────┘  └──────────────────────┘   │
└─────────┼───────────────────────────────────────────────────────┘
          │ SSH
┌─────────▼───────────────────────────────────────────────────────┐
│                    EC2 Runtime Host                              │
│                                                                 │
│   ┌─────────┐  ┌──────────┐  ┌─────────┐  ┌────────────────┐   │
│   │ App     │  │ Postgres │  │  Redis  │  │   Compute      │   │
│   │Container│  │Container │  │Container│  │   Instance      │   │
│   └─────────┘  └──────────┘  └─────────┘  └────────────────┘   │
│                        Nginx (reverse proxy)                    │
└─────────────────────────────────────────────────────────────────┘

🧠 How It Works — Technical Deep Dive

1. Chat Orchestration (LangGraph)

The core of Cloudgen is a stateful LangGraph pipeline (agent.ts) that processes every user message through a directed graph of nodes:

START ──► parse_intent ──► retrieve_context ──► route_intent
                                                    │
                                    ┌───────────────┼────────────┐
                                    ▼               ▼            ▼
                              generate_plan    answer_question   ...
                                    │
                                    ▼
                                save_plan ──► respond ──► END

parse_intent — Regex + heuristic parser extracts repo URLs, expected user counts, database requirements, and whether the user wants to plan, deploy, or ask a question
retrieve_context — Queries the RAG index (pgvector cosine similarity) for relevant internal docs and repo READMEs
generate_plan — Invokes the multi-agent planning pipeline when a provisioning intent is detected
respond — Streams a contextual reply back using Gemini, or falls back to a templated response

2. Multi-Agent Planning Pipeline

When a deployment intent is detected, three specialized agents collaborate (planning.ts):

Agent	Role	Output
Intent Agent	Extracts high-level goals — expected users, latency sensitivity, which resources are needed (app/postgres/redis/instance)	`IntentAgentOutput`
Repo Inspector Agent	Fetches the GitHub repo structure, `package.json`, `Dockerfile`, and `requirements.txt` to infer runtime, framework, build commands, and app port	`RepoInspectorOutput`
Capacity Agent	Takes the outputs of the previous two agents and determines resource sizing (CPU, memory, replicas), tier selection, and cost estimation	`CapacityAgentOutput`

Each agent calls Gemini 2.0 Flash via a structured JSON prompt (llm.ts). If no API key is available, each agent has a deterministic fallback so the system remains fully functional without any LLM.

The pipeline produces:

A DeploymentPlan stored in Postgres
A YAML step file (deployment-plans/<plan-id>.yaml) describing the exact Docker commands to execute

3. RAG Engine (pgvector)

Cloudgen uses Retrieval-Augmented Generation to ground agent responses in real documentation (rag.ts):

Internal docs (architecture, runbooks) are chunked and embedded into pgvector
Repository READMEs from connected GitHub repos are fetched and indexed
At query time, a deterministic 64-dim embedding is computed and a cosine similarity search retrieves the most relevant chunks
Retrieved chunks are injected as context into the LLM prompt and returned as citations in the chat response

4. Deployment Executor (SSH + Docker)

After plan approval, the Deployer (deployer.ts) triggers the Executor (executor.ts):

SSH tunnel to the runtime EC2 host using key-based authentication
Clone the GitHub repo on the remote host
Auto-generate Dockerfile if missing (for Node.js repos)
Build the Docker image
Provision each resource as a Docker container with CPU/memory limits:
- docker run with --cpus, --memory, port mappings
- Postgres containers use postgres:16-alpine
- Redis containers use redis:7-alpine
- Compute instances use ubuntu:22.04 with long-running entry points
Health check — polls the container endpoint until it responds
Configure Nginx reverse proxy route (optional)
Return endpoints — live app URL + database/cache connection strings

5. Data Model (Prisma + PostgreSQL)

The control plane persists all state via Prisma ORM (schema.prisma):

Model	Purpose
`Project`	A linked GitHub repo with name, slug, branch
`ChatSession`	Conversation thread tied to a project
`ChatMessage`	Individual messages with role and citations
`DeploymentPlan`	AI-generated plan with inputs, decision, cost, rationale
`Deployment`	Execution record with status, logs, and live URLs
`RagDocument` / `RagChunk` / `RagEmbedding`	RAG corpus with pgvector embeddings

🛠️ Tech Stack

Layer	Technology
Frontend	Next.js 15, React, Tailwind CSS, NextAuth.js
Backend	Fastify 5, TypeScript, Zod validation
Agent Framework	LangGraph (stateful graph orchestration)
LLM	Gemini 2.0 Flash (streaming + structured JSON output)
Database	PostgreSQL + pgvector (control plane + RAG)
ORM	Prisma with raw SQL for vector operations
Deployment Runtime	Docker containers on EC2 via SSH
Monorepo	npm workspaces

🚀 Getting Started

Prerequisites

Node.js 20+
PostgreSQL 15+ with pgvector extension
(Optional) Gemini API key for AI-powered planning
(Optional) EC2 host with Docker for live deployments

Setup

# Install dependencies
npm install

# Generate Prisma client
npm run db:generate

# Run database migrations
npm run db:migrate -- --name init

# Seed initial data
npm run db:seed

# Start development servers
npm run dev

Environment Variables

Create apps/api/.env:

DATABASE_URL="postgresql://postgres:postgres@localhost:5432/cloudgen"
PORT=4000

# LLM (optional — system works without it via fallbacks)
GEMINI_API_KEY=""
GEMINI_MODEL="gemini-2.0-flash"

# Runtime deployment host (leave empty for local preview mode)
RUNTIME_SSH_HOST=""
RUNTIME_SSH_USER="ubuntu"
RUNTIME_SSH_PORT="22"
RUNTIME_SSH_KEY_PATH="/path/to/key.pem"
RUNTIME_BASE_DIR="/tmp/cloudgen-apps"
RUNTIME_PUBLIC_BASE_URL="http://your-ec2-ip"

# Resource limits
ACTIVE_APP_CAP="8"

Services

Service	URL
Web Dashboard	http://localhost:3000
API Server	http://localhost:4000
Health Check	http://localhost:4000/health

📡 API Reference

Method	Endpoint	Description
`POST`	`/api/projects`	Create a new project (link a GitHub repo)
`GET`	`/api/projects/:id`	Get project details
`GET`	`/api/projects/:id/resources`	Get provisioned resources for a project
`POST`	`/api/chat`	Send a chat message (triggers planning if needed)
`GET`	`/api/sessions/:id`	Get full chat session history
`POST`	`/api/plans/:id/approve`	Approve a deployment plan
`GET`	`/api/plans/:id/steps`	Get YAML deployment steps for a plan
`POST`	`/api/deploy`	Trigger deployment of an approved plan
`GET`	`/api/deployments/:id`	Get deployment status and logs

🔄 End-to-End Flow

User: "Deploy https://github.com/user/app with Postgres for 500 users"
  │
  ├──► Intent Parser: repo URL, 500 users, postgres needed
  ├──► RAG Retrieval: fetch relevant architecture docs
  ├──► Intent Agent: high-level goals + resource list
  ├──► Repo Inspector: Node.js, has Dockerfile, port 3000
  ├──► Capacity Agent: ac.pro tier, 1 CPU, 1GB RAM, ~$34/mo
  │
  ▼
Plan Generated:
  • App container (Node.js, port 3000)
  • Postgres container (postgres:16-alpine)
  • Estimated cost: $34/mo
  • YAML steps file written
  │
  ├──► User reviews plan + rationale
  ├──► User approves
  │
  ▼
Deployment:
  • SSH into EC2 host
  • Clone repo, build Docker image
  • Start app + postgres containers
  • Health check passes
  • Nginx route configured
  │
  ▼
Result: "Your app is live at http://host:21042 🎉"

🧪 Smoke Test

Run the full end-to-end flow against a running instance:

npm run smoke

Screenshots:

My Experience with GitHub Copilot CLI

Cloudgen is a complex product. Orchestrated AI agents, a full API, real provisioning, and a dashboard. We used GitHub Copilot CLI from the terminal throughout the build. It didn’t just speed up typing, it helped us design and implement systems we’d have hesitated to tackle alone. Below is how we used it, the prompts that worked, and how you can use Copilot CLI more effectively on your own projects.

How we used Copilot CLI: interactive vs one-off

Copilot CLI has two modes we relied on every day.

Interactive mode (default). We’d run copilot in the project root and stay in a session. That’s where we did most of the work: multi-file changes, refactors, and “add a new node to the graph” style tasks. The back-and-forth let us refine in small steps (“now add error handling for when the repo URL is invalid”) without rewriting long prompts. We’d confirm we trusted the folder when asked, then work in that directory and its subdirectories.

Programmatic mode. For quick, single-shot tasks we used -p or --prompt. For example:

copilot -p "Add a Zod schema for POST /api/chat: sessionId optional UUID, projectId optional UUID, message required string min 1"

That gave us a schema and a route stub we could paste into the Fastify app. We used this for validation schemas, small utilities, and one-off scripts (e.g. “generate a bash script to run the API and web app with one command”). For anything that would modify or run files, Copilot asked for approval first, so we stayed in control.

Giving Copilot context: @file and scope

Copilot works better when it sees the exact code you care about. We used @file a lot.

Examples we actually used:

Explain @apps/api/src/agent.ts and list all graph nodes and what they write to state

So we could onboard quickly and later ask for new nodes without breaking the graph.
In @apps/api/src/intent.ts add detection for "no database" and set databaseRequired to false. Keep the same ParsedIntent shape.

One file, one behavior change, clear outcome.
@apps/api/src/planning.ts the Capacity agent output needs a new field 'reasoning: string[]'. Add it to the interface and to the fallback object.

Copilot had the interfaces and the fallback logic in context, so the change was consistent.
Fix the bug in @apps/api/src/rag.ts: chunkContent is sometimes undefined when we build the citation. Add a filter.

We pointed at the file and described the symptom; Copilot proposed a safe fix.

We also kept sessions focused. When we switched from “agent graph” work to “frontend” work, we ran /clear and started a new mental context. That cut down on Copilot suggesting changes to the wrong layer. When we needed to touch both API and web app, we stayed in one session and mentioned both: “Update the API to return estimatedCostUsd in the plan payload and add a cost row in the plan review card in the project page.”

Plan before you code: /plan for big features

For larger chunks of work we used plan mode. Instead of “implement this whole thing,” we asked Copilot to design the steps first.

Example prompts:

/plan Add a deployment plan approval flow: API endpoint POST /api/plans/:id/approve, update plan status in DB, return updated plan. Frontend: Approve button that calls the endpoint and then shows a “Deployment started” state.
/plan Implement streaming chat: the /api/chat response should stream chunks. Frontend should consume the stream and append to the message content. Keep existing non-streaming fallback.

What we got: a structured plan (often saved to something like plan.md in the session), with checkboxes and ordered steps. We could review it, ask for edits (“add a step to handle approval rejection”), and only then say “implement this plan.” That reduced wrong turns and kept the codebase consistent. For quick bug fixes or single-file edits we didn’t use /plan, only for multi-file or multi-layer features.

Prompt examples that worked for Cloudgen

Here are real prompt patterns we used, so you can adapt them.

Orchestration and state (LangGraph)

“In agent.ts we have a state graph. Add a new node retrieve_context that runs after parse_intent. It should call retrieveContext from rag.js with the message, put the result in state.chunks, and pass through to the next node. Use the same Annotation pattern as the other nodes.”
“The respond node should include citations from state.chunks in the streamed reply. Each citation needs source title and chunk text. Update the streamChatReply call to pass citations.”
“Our graph has a branch: if intent.wantsPlan we go to generate_plan, else if intent.asksQuestion we go to answer_question. Add a default branch that sets reply to a short ‘I didn’t understand’ message and goes to END.”

Planning pipeline and types

“In planning.ts add a fallback for IntentAgentOutput when the LLM is unavailable: expectedUsers 100, databaseRequired true, requestedResources ['app'], confidence 0.5. Match the interface exactly.”
“We’re adding estimatedCostUsd to the plan. Update: 1) CapacityAgentOutput and the fallback in planning.ts, 2) the place we save the plan to the DB in agent.ts, 3) the DeploymentPlan type in the Prisma schema if needed.”
“Generate the TypeScript interface for DeployStep: id string, type enum (prepare_workspace, clone_repo, build_image, run_app, run_postgres, health_check, configure_route), target string, description string.”

API and validation

“Add a Fastify route POST /api/plans/:id/approve. Body: { approved: true, approvedBy?: string }. Validate with Zod. On success call approvePlan(planId) and return { plan }.”
“We need GET /api/deployments/:id that returns status, logsJson, appUrl, containerName. Use getDeployment from deployer.js. Return 404 if not found.”

Database and RAG

“Our Prisma schema has Project, ChatSession, ChatMessage, DeploymentPlan, Deployment. Add a RagDocument model: id, sourceType enum (INTERNAL, RUNBOOK, REPO_README), sourceRef unique, title, content, createdAt, updatedAt. Add RagChunk with documentId and content.”
“In rag.ts the retrieveContext function should take a query string, compute an embedding (use the existing deterministic embedding if no API key), query RagChunk by cosine similarity on the embedding column, and return the top 5 chunks with title and sourceRef.”

Frontend

“In the project page, add a section that shows the latest deployment plan: rationale, resources list, estimated cost. If there’s no plan, show ‘No plan yet.’ Use the existing API types.”
“Wire the Approve button to POST /api/plans/:id/approve and then POST /api/deploy with projectId and planId. Disable the button while loading and show a toast or inline message on error.”
“The deployment logs should update in real time. Add a polling loop that calls GET /api/deployments/:id every 2 seconds while status is QUEUED or BUILDING, and append new log entries to the list.”

Provisioning and reliability

“The executor runs a sequence of steps. If any step fails, we should push the error message to logs, set status to FAILED, and stop. Don’t run the next step. Add a try/catch around each step and update the deployment record.”
“Add a health check step after the app is running: GET the app URL with a 30s timeout, retry up to 5 times with 5s delay. If it never responds, mark deployment as FAILED and add ‘Health check failed’ to logs.”

We were specific about inputs and outputs (e.g. “return the top 5 chunks with title and sourceRef”) and broke big features into small prompts (one node, one endpoint, one UI block). That gave us code that matched our architecture instead of generic snippets.

Slash commands we used every day

We leaned on a few slash commands to work faster and keep context clean.

Command	How we used it
`/clear`	Between unrelated tasks (e.g. after finishing the agent graph and before starting the dashboard). Clears conversation history so Copilot doesn’t drag in old files or decisions.
`/plan`	Before implementing a new feature or flow. Gets a step-by-step plan we can edit, then “implement this plan.”
`/cwd`	When we needed to scope Copilot to `apps/api` or `apps/web` only. We’d `/cwd apps/api` then ask for API-only changes.
`/model`	We switched to a more capable model for the orchestration and planning code (complex state and types), and kept a faster model for simple CRUD and UI.
`/help`	To discover other commands (e.g. `/context`, `/session`, `/delegate`) when we needed them.
`/review`	Before committing. “Review the changes in my current branch against main for potential bugs and security issues.”

Pro tip: If you only remember three, use /clear, /cwd, and /plan. They give you control over context, scope, and how much “thinking” Copilot does before writing code.

Custom instructions so Copilot matched our stack

We added a .github/copilot-instructions.md (or repo-level instructions) so Copilot didn’t guess our conventions.

We wrote things like:

Build commands: npm run dev (root, runs api + web), npm run db:migrate (from root, runs API migrations), npm run typecheck (root).
Code style: TypeScript strict, ESM (import/export), prefer async/await, use Zod for request validation.
Structure: Backend in apps/api/src, frontend in apps/web/app and components, shared types in apps/web/lib/types.ts and API types.ts.
Workflow: After adding an API endpoint, export it from the right module and add the route in index.ts; after changing Prisma schema, run db:generate and db:migrate.

That way, when we said “add an endpoint to list deployments for a project,” Copilot put it in the right place and used Zod and our existing patterns. Short, actionable instructions worked better than long essays.

How to use Copilot CLI more effectively (what we learned)

Break down complex tasks. “Implement the full chat flow” is too big. We got better results with: “Add the parse_intent node,” then “Add the retrieve_context node and wire it after parse_intent,” then “Add the branch that routes to generate_plan or answer_question.” Same for the frontend: one component or one API integration per prompt.

Be specific about inputs and outputs. “Add a function that fetches the plan” is vague. “Add a function getPlan(planId: string) that calls GET /api/plans/:id and returns the plan JSON or null if 404” is something Copilot can implement accurately.

Use @file for precision. When the change is in one file or you need to avoid touching others, put the path in the prompt. It reduces wrong-file edits and keeps context small.

Plan mode for multi-step work. For anything that touches API + DB + frontend, or several modules, we used /plan first. We reviewed the plan, adjusted it, then said “implement this plan.” Fewer rollbacks and cleaner diffs.

Validate Copilot’s output. We always ran npm run typecheck and the relevant tests after accepting changes. We especially reviewed anything that touched deployment or user data. Copilot is a powerful draft, not a substitute for review.

Clear context when switching tasks. /clear between “backend” and “frontend” or between features kept suggestions relevant. We also closed files we weren’t working on so Copilot didn’t pull them in unnecessarily.

What actually changed for us

We could think in product terms. Describe what should happen next, get code that matched. Less jumping between docs and editor.
Complex systems felt buildable. The orchestration and provisioning layers are the kind of thing that usually take weeks to get right. Copilot CLI gave us a strong first pass so we could refine behavior and edge cases instead of starting from zero.
Consistency across the stack. By describing our conventions in natural language (and in copilot-instructions), we kept naming, error handling, and structure consistent across backend, agents, and frontend.

We still review and test everything, especially where real provisioning and user data are involved, but Copilot CLI let us build a product that sells the idea of “deploy by talking,” instead of getting stuck in the plumbing.

Summary

Cloudgen is a product that lets you deploy your app by describing what you need in chat. We handle the complexity, planning, sizing, provisioning, and giving you live URLs and connection strings, so you don’t have to. We built it with GitHub Copilot CLI, and it’s what made it realistic to ship something this involved: multi-agent orchestration, a full API, real provisioning, and a polished dashboard, without drowning in boilerplate. We’re excited to keep improving Cloudgen, and we will soon launch it to the public for use. A lot of tools are also coming that help you deploy better. Thanks to copilot we can ship fast!!

Thanks to the GitHub Copilot team for running this challenge.

Appwrite Submission Post MerkleWrite- A decentralised blogging website built using ethereum, defi and appwrite

MOHIT BHAT — Thu, 12 May 2022 19:13:55 +0000

Overview of My Submission

About

This is Decentralized content sharing platform made on top of ipfs, Defi and Ethereum. Nowdays content creation is centralised and are subject to changes or partiality by the site owners. To support the content creators and provide them with equal rights and profits, merklewrite is made!

In merkleWrite you can write a blog with images and markdown content. The users will need to pay 1 DAI as subscription fee for 30 days to see the blog's. The DAI taken from user's are then sent to Compound for generating Interest(In the Form Of CTokens). The Dai Taken and Interest generated are then equally divided between content creators who has Likes more than specified limit(Currently set at 10). You can transfer Subscription to other ethereum address, get paid once in a month and update your profile's to let world know you!
The Best part Is All is Decentralized with a no code support from appwrite

Blockchain Technologies used

Ethereum
Matic Network
Portis
DEFI
Dai Stable coin
Compound
Ipfs
ERC20

TechStack Used

Blockchain
Nodejs
HTML/CSS
Boostrap
Javascript
Appwrite

Features

User can write blog(MarkDown Supported)

To write a blog the user needs to go to write section
He need to login using Portis wallet or create one
Need's to put title, featured Image and Content(In Markdown) and submit it
Pay the gas fee, hola! Blog uploaded!! ### Profile/Account Section It includes:
Subscribe To see Blog's
Transfer Your Subscription
Update name, Profile Image and Cover Image
See Subscription Details, No of total likes on the post's, Get paid for content and see all blog that you uploaded

## Other features

You can like blog's(thanks to appwrite database api)
You can see the Author Profile and all his/her Blogs

To Run The code

Clone the Repo
Go to project Directory and open Cmd
Run npm install
Run npm start
Head to http://127.0.0.1:5000/

How this is built

Blokchain: The blockchian used here is ethereum and polygon(on testnets). The post metadata data is stored on smart contract which is built using solidity. The post content and images and other stuff are first uploaded to ipfs(interplanetary file system) and the hash returned is then stored onto the smart contract. This saves gas cost and provides more security and feasibility.

The payments are take through portis wallet and sent to compound protocol(which gives us back ctokens) which basically generated interest on it. Ones months end payments are calculated on the basis of how many creators are there, and there likes, views and then the amount is taken back from compound and given to creators. The interest generated is sent to admin(us).

Frontend: Its built using html, css, javascript, bootstrap. Web3js is used to make communication with web3 wallets, ethereum/polygon blockchain.

Backend: There is a small backend working for auth and storing likes on post which helps in distribution of creators funds. appwrite database is connected to nodejs backend and routes are created to handle application data. It act as a intermediary node between connecting appwrite, blockchain, ipfs and frontend.

Appwrite: Appwrite is really awesome. I was able to setup and connect all these things in very short span of time because of appwrite. appwrite is deployed using digital ocean image.

Then project is created and web app is added to it and database is created which handles like data. Some apprite functions are also used for data interaction btw blockchain and backend.

Submission Category:

Web3 Wunderkinds

Links

Website 👉 https://merklewrite.herokuapp.com/

Github 👉 https://github.com/mbcse/app-write-dev

Appwrite Link 👉 http://68.183.246.221/

YouTube 👉 https://youtu.be/qbnQlZge98Q

Hola! Decentralized Blogging started

Deployed On Matic Mumbai Testnet

Wallet Support by Portis

Backend Support by Appwrite

LIVE WEBSITE LINK: https://merklewrite.herokuapp.com/

IPFS Accessed through Infura