"Pixelator" is a simple web app that turns uploaded images into retro-style pixel art. My goal was to build it with the help of a coding agent, host the repository online, and deploy the app to the internet in a secure and professional way. It is intended for password protected private use only. And - disclaimer - consider: I am not a software engineer.er.
BUILDING IT WITH CLAUDE CODE
I built Pixelator inside Claude Code, Anthropic's terminal-based coding agent, working conversationally rather than writing every line by hand. I'd describe what I wanted - "turn any uploaded photo into retro pixel-art game graphics using a model on Replicate.com" - and Claude Code did the implementation: scaffolding the Node.js/Express backend, writing the upload and polling logic, building the frontend, wiring in the Replicate API, then adding authentication and the resolution/upscaling logic in later rounds as the requirements grew.
"I almost knew what it was doing!"
It didn't just write code and hand it over - it tested its own work before I saw it: starting the server locally, pushing real test images through the full pipeline with curl, opening the app in a sandboxed browser to click through the actual interface, catching real bugs along the way, and fixing them before asking me to look. My role was direction and review: deciding (rubber-stamping...) the architecture, resolution, security posture, approving what got committed and pushed.
GITHUB: THE SOURCE OF TRUTH
Every change lives in a git repository pushed to GitHub. That repo is the single source of truth for the code - nothing important exists only on my laptop. It's also the connection point for deployment: Render.com watches this repository directly, so the moment a change is pushed to the main branch, Render notices and rebuilds the live app automatically, with no manual step in between.
"GitHub made me feel comfortable!"
GitHub never sees any secrets. The .env file that holds the real API token and password is explicitly excluded via .gitignore - anyone browsing the public repository sees only placeholder example values, never live credentials.
PUBLISHING ON RENDER
Render.com is the host that actually keeps the app running. It's use was proposed by the Claude Code agent. I connected it to the GitHub repo through a "Blueprint" - a small render.yaml file committed to the repo that tells Render how to build and run the project and which environment variables it needs to work.
"I have no idea. Safely stepping into new territory!"
The sensitive values - the Replicate API token, the Pixelator login username and password - are marked as secrets in that file. That means Render doesn't try to pull them from the repo at all; instead, they're typed directly into Render's own dashboard, where they're stored in Render's environment variable vault and only ever injected into the running server process at deploy time. From that point on, every git push to main triggers an automatic rebuild and redeploy - no manual server administration required.
WHY AUTHENTICATION, AND WHY A "SAFE PLACE" FOR SECRETS
"Since I’m not a software engineer, I desperately hope this is actually the right architecture." ***
Two separate risks are easy to conflate, but they need two separate fixes.
Risk one: the API key leaking. If the Replicate API token ever reached the browser - baked into frontend JavaScript, for instance - anyone could open developer tools, copy it, and start generating images on my account, at my expense.
Risk two: the door being unlocked. Even with the key perfectly safe, a public URL is still a door anyone can walk through. Without a lock on it, anyone who found or guessed the link could use the app freely and still spend my money - not by stealing the key, but simply by routing generation requests through my own server, which holds the key on their behalf.
Both risk need mitigation for this to be genuinely safe to put on the internet: one guards the key itself, the other guards the door to using it.
"Final verdict: That was fun and - crazy - all done in less than two hours!"
*** P.S. I ASKED GEMINI TO REVIEW THE SET-UP
... and it made some proposal that were checked, improved and re-deployed by Claude Code.
