Neploy

Thesis

One-click deployment for early-stage builders. Push code, get a running application — no Dockerfiles to write, no CI/CD to configure, no infra to provision. The bet: infrastructure complexity is the biggest barrier to shipping for solo developers and small teams, and most of that complexity can be auto-detected.

Status

abandoned (portfolio: Archived). Frontend repo last pushed 2025-06-02; build-service (the Lambda runtime that almost certainly powered it) pinned as standalone. The engine outlived the product.

Stack

Detection: analyzes repo to identify framework, runtime, and build requirements. Generates a build plan without requiring a config file.
Build: containerizes the app using optimized multi-stage Dockerfiles derived from the detected plan.
Deploy: AWS primitives — ECS for containers, ALB for routing, Route53 for DNS, with zero-downtime rolling updates.
Runtime for Next.js apps: Lambda-based SSR + static serving (see build-service).
Trigger: git push. No dashboard clicks, no manual steps.

Key decisions

Auto-detection over config files: requiring neploy.yml would defeat the purpose. Ask only for what can't be inferred.
Docker as the universal packaging format: every app becomes a container, regardless of language. One abstraction for the deploy target.
AWS primitives over building a cloud: 90% of the value at 10% of the multi-year cost of custom infra.
Scoring model for multi-framework monorepos: a Next.js app with a custom server plus a Python ML service plus a static site can coexist; the detector scores framework markers to pick a build strategy.

Learnings

Build detection is harder than it looks. Framework markers are noisy — many projects set up scaffolding they never finish.
Pinning the engine (build-service) separately from the product suggests the engineering artifact has more durable value than the product wrapper did. Worth remembering for future archived projects: extract the reusable core before sunsetting.

Outcomes

Reduced deployment time from hours to seconds for early-stage projects (portfolio).
Archived status implies the product didn't find PMF; no recorded reason. Likely cause candidates: market already served by Vercel/Railway/Render for the Next.js case; custom-infra economics don't pencil at solo-dev pricing; founder attention moved to Orqys / Synapse.

Open questions

Why archived — commercial, personal, or technical?
Is build-service still in use anywhere (consulting, internal deploys), or truly frozen?
Would Neploy's positioning work today in the agent-deploys-agents world (e.g., paired with Orqys)?