How We Built Roptal — From Repo to Live Endpoint in One Command

In February 2025, I was deploying my 14th ML model of the month. Different frameworks (FastAPI, Flask, Streamlit), different clouds (AWS, Hugging Face Spaces, RunPod), different hardware requirements (CPU, T4, A100). Every deployment took 2-4 hours of Dockerfile wrangling, IAM permission debugging, and waiting for cloud provisioning.

I thought: there has to be a better way.

That frustration became Roptal — an orchestration layer for AI deployment. Here's how we built it, what we learned, and where we're going.

The Problem We Set Out to Solve

ML deployment isn't one problem. It's a stack of interconnected problems:

1. Repository Analysis: What framework? What Python version? CUDA? System libraries? Most repos don't document this.
2. Containerization: Writing production Dockerfiles from scratch. Getting layers right. Security hardening.
3. Cloud Provisioning: Different APIs for every cloud. Different auth. Different CLI tools.
4. Operations: Monitoring, health checks, canary deployments, rollbacks, cost tracking.
5. Multi-Cloud: Moving a model from AWS to GCP means rewriting everything.

The core insight: the deployment target (cloud provider) should be decoupled from the deployment artifact (Docker container). If you generate a good Dockerfile, you can deploy anywhere.

Architecture

Roptal has four layers:

1. Analysis Layer (Python)

The CLI (ezdeploy-cli) and backend analyzer scan repositories to build a deployment profile:

$ roptal scan
✓ Detected framework: FastAPI 0.104
✓ Python version: 3.11.8
✓ CUDA version: 12.1
✓ Port: 8000
✓ Entry point: main.py:app
✓ System dependencies: libgl1, ffmpeg, libgomp1

This drives Dockerfile generation. Without it, you're guessing.

2. Generation Layer (Jinja2)

We built a template engine that produces production-grade Dockerfiles:

• Multi-stage builds (build → runtime)
• Slim base images (python:3.11-slim, not python:3.11)
• Non-root user (uid 1000)
• Layer caching optimization
• Health check endpoint
• Graceful shutdown handling

The generated Dockerfile is viewable and editable. You can tweak it before deploying.

3. Orchestration Layer (Celery + Redis)

Deployment is an async workflow. We use Celery for:

• Building Docker images (can take 5-15 minutes)
• Pushing to container registries (ECR, ACR, GCR)
• Provisioning cloud resources (SageMaker endpoints, Cloud Run services, etc.)
• Running canary deployments and health checks
• Monitoring and alerts

Celery workers run in parallel, so multiple deployments don't block each other.

4. Control Plane (FastAPI + React)

The API (FastAPI 0.104) handles:

• Repository management (GitHub App integration)
• Credential storage (encrypted at rest)
• Deployment operations (create, monitor, cancel, rollback)
• Billing and subscription management

The frontend (React + TypeScript + Vite) provides:

• Repository dashboard
• Deployment wizard
• Live log streaming (SSE)
• Cost explorer
• Model registry (coming soon)

What We Learned

Lesson 1: BYOC Is Harder to Build, Better for Users

Building for BYOC means integrating with 8+ cloud APIs. Each has its own auth, pricing model, and quirks. AWS SageMaker alone has 200+ API operations.

But the user benefit is massive: no vendor lock-in, direct cloud billing, full security control. It's worth the engineering investment.

Lesson 2: CI/CD Is the Real Product

The core feature isn't "deploy a model." It's "deploy a model safely and repeatedly." Canary deployments, blue-green rollouts, traffic splitting, health-verified promotion — these are what make the platform useful, not the initial deploy.

Lesson 3: Monitoring Is Not Optional

Every deployment needs monitoring from day one. We built:

• SSE log streaming (real-time, per-deployment)
• Health check loop (every 30s, alerts on failure)
• Cost tracking (per-cloud, per-deployment, with forecasts)
• Drift detection (PSI calculation for input/output distribution changes)

Without monitoring, you're flying blind.

Lesson 4: Start with the CLI

The ezdeploy-cli was built before the web app. It does one thing: scans a local directory and outputs a JSON file. This simple tool:

• Validated our analysis logic
• Attracted early users who prefer CLI
• Became the foundation for the web app's repository analysis

Ship the smallest useful thing first.

The Stack

• Frontend: React 18, TypeScript, Vite, TailwindCSS, Framer Motion
• Backend: Python FastAPI, Celery, Redis, SQLAlchemy (via Supabase)
• API Gateway: Go (high-performance proxy for auth, rate limiting)
• Database: Supabase (PostgreSQL) for structured data, Redis for caching/queues
• Auth: Supabase GoTrue (JWT-based)
• Payments: Lemon Squeezy, Stripe
• Email: Resend
• Hosting: Vercel (frontend), Azure Container Apps (backend), Hugging Face Spaces (auxiliary)

What's Next

Roptal is in early access. We're onboarding teams now. What's coming:

• MCP Server: AI agents can deploy models via the Model Context Protocol
• Model Registry: Version tracking, metadata, lineage
• Fine-tuning: Managed fine-tuning pipelines on your cloud
• Advanced release patterns: A/B testing, shadow deployments, circuit breakers
• More clouds: Oracle, Vercel, more RunPod serverless options

Try It

We're launching with early access soon. The platform is built by ML engineers, for ML engineers. No Kubernetes. No YAML. No cloud-specific config. Just connect your repo and deploy.

Apply for early access →

---

Roptal is built by Oryvo AI and backed by Microsoft for Startups with $100K+ in cloud credits. Follow us on GitHub and LinkedIn.