#developer-productivity — Public Fediverse posts

So now we've entered the era of "HATCHA" - a delightful tool that somehow proves you're an alien 👽 rather than a human. #GitHub has decided to test your humanity with a #CAPTCHA, and then swiftly revoke it with #HATCHA. 🤖 Because, clearly, nothing says "developer productivity" like existential identity crises in the login process! 🙃
https://github.com/mondaycom/HATCHA #developerproductivity #identitycrisis #HackerNews #ngated

So now we've entered the era of "HATCHA" - a delightful tool that somehow proves you're an alien 👽 rather than a human. #GitHub has decided to test your humanity with a #CAPTCHA, and then swiftly revoke it with #HATCHA. 🤖 Because, clearly, nothing says "developer productivity" like existential identity crises in the login process! 🙃
https://github.com/mondaycom/HATCHA #developerproductivity #identitycrisis #HackerNews #ngated

5-Agent Framework for Code Audits

I’ve been seeing the same anti-pattern everywhere lately.
Someone opens Cursor, Copilot or Claude and pastes a giant prompt:

 You are a Principal Security Engineer, Staff Node.js Engineer, and Senior SRE performing a production-grade audit of this codebase.  Your mission is NOT to explain the code.  Your mission is to aggressively find:   1. Security vulnerabilities  2. Reliability issues  3. Logic bugs  4. Performance bottlenecks  5. Race conditions  6. Data integrity issues  7. Scalability problems  8. Operational risks  9. Bad architectural decisions  10. Technical debt that could cause future incidents   Codebase stack:  - NodeJS  - Express  - TypeScript  - (discover additional technologies automatically)   Rules:   - Think like an attacker first.  - Then think like an SRE responsible for keeping production alive at 3AM.  - Then think like a senior engineer maintaining this system for 5 years.  - Be skeptical of every assumption.  - Never assume code is safe because it works.   For every file you inspect, evaluate the following categories.   ## SECURITY CHECKLIST   ### Authentication  - Missing authentication  - Broken authentication  - Insecure session management  - JWT issues  - Token expiration issues  - Missing token validation  - Weak secrets handling  - Secret leakage   ### Authorization  - IDOR vulnerabilities  - Privilege escalation risks  - Missing ownership validation  - Missing role checks  - Overly broad permissions   ### Input Validation  - SQL Injection  - NoSQL Injection  - Command Injection  - Path Traversal  - Prototype Pollution  - XSS  - SSRF  - Open Redirects  - Unsafe deserialization  - Header injection   ### API Security  - Missing rate limiting  - Missing request size limits  - Missing CORS restrictions  - Information leakage  - Verb tampering  - Sensitive endpoint exposure   ### Secrets Management  - Hardcoded secrets  - API keys in code  - Credentials in configs  - Sensitive logs   ### Dependencies  - Dangerous packages  - Deprecated packages  - Unmaintained packages  - Supply chain risks   ### Infrastructure  - Unsafe environment variable usage  - Missing security headers  - Missing HTTPS enforcement  - Dangerous Express configuration   ---   ## RELIABILITY CHECKLIST   Find:   - Missing try/catch blocks  - Unhandled promise rejections  - Silent failures  - Swallowed exceptions  - Missing timeouts  - Missing retries  - Infinite loops  - Resource leaks  - Memory leaks  - File descriptor leaks  - Database connection leaks  - Event listener leaks   ---   ## DATA INTEGRITY CHECKLIST   Find:   - Non-atomic operations  - Race conditions  - Concurrent update issues  - Duplicate writes  - Missing transactions  - Inconsistent states  - Event ordering problems  - Partial failures   ---   ## PERFORMANCE CHECKLIST   Find:   - N+1 queries  - Sequential async code that should be parallelized  - Excessive awaits inside loops  - Blocking CPU work  - Large memory allocations  - Missing caching opportunities  - Excessive serialization  - Repeated computations   Estimate impact whenever possible.   ---   ## EXPRESS SPECIFIC CHECKLIST   Inspect:   app.ts  server.ts  middleware/  routes/  controllers/  services/  repositories/  models/   Look for:   - Missing helmet  - Missing compression  - Missing body size limits  - Missing rate limiting  - Missing request validation  - Missing centralized error handling  - Missing graceful shutdown  - Missing health checks  - Missing request IDs  - Missing correlation IDs   ---   ## TYPESCRIPT CHECKLIST   Find:   - use of any  - unsafe type assertions  - ignored compiler errors  - null/undefined bugs  - impossible states  - weak interfaces  - duplicate types   ---   ## OBSERVABILITY CHECKLIST   Verify:   - Structured logging  - Error tracking  - Metrics  - Health endpoints  - Distributed tracing  - Audit logs  - Correlation IDs   ---   ## OUTPUT FORMAT   Do NOT dump all findings.   Prioritize findings by severity.   Use this exact format:   # CRITICAL   Issue:  Location:  Impact:  Attack scenario:  Evidence:  Fix:   # HIGH   Issue:  Location:  Impact:  Evidence:  Fix:   # MEDIUM   Issue:  Location:  Impact:  Evidence:  Fix:   # LOW   Issue:  Location:  Impact:  Evidence:  Fix:   # ARCHITECTURAL IMPROVEMENTS   1.  2.  3.   # TOP 10 ACTION ITEMS   Order by highest ROI and risk reduction.   IMPORTANT RULES:   - Never speculate.  - If evidence is insufficient, explicitly say:    "Potential issue - needs verification."   - Show the exact file and line numbers whenever possible.   - If you cannot verify a vulnerability, do not present it as fact.   - Suggest concrete code fixes, not generic advice.   - Think adversarially. 

Be a principal security engineer, SRE, performance engineer and senior TypeScript expert.
Audit my entire codebase before production.

Sounds smart but usually produces mediocre results.

Here’s the pattern I’ve noticed:

• The first few findings are excellent.
• Then the model starts skimming.
• Then it starts hedging.
• Eventually it turns into a summary instead of an audit.

This isn’t a prompting problem.

It’s a job design problem – Looks at this:

 ❌ Giant Agent   Codebase     ↓  One Super Prompt     ↓  40 mixed findings     ↓  Nobody reads it    ✅ Specialized Agents              Security                 ↓  Codebase → Reliability                 ↓            Performance                 ↓              Platform                 ↓            TypeScript          ↓ ↓ ↓ ↓ ↓      One merged triage doc 

We’re asking one agent to do five different jobs simultaneously.
Humans don’t work that way.
Engineering organizations don’t work that way. LLMs don’t either.

Treat AI agents like engineering teams

In a healthy engineering organization, you don’t ask one person to be:

• The security engineer
• The SRE
• The performance expert
• The platform engineer
• The TypeScript expert

You specialize.
Do the exact same thing with your AI agents.

I call this the 5-Agent Production Audit Framework.

Agent #1: Security & Authentication

Persona: Principal Security Engineer

This agent thinks like an attacker. Your red team.

Scope:

• Authentication
• Authorization
• Input validation
• Injection vulnerabilities
• XSS
• SSRF
• Secrets management
• Dependency risks

Run this one first.

Security findings are usually the highest severity and other audits will often reference the same code paths.

Agent #2: Reliability & Data Integrity

Persona: Senior SRE (He wrote this SRE book)

This agent asks one question:

What happens at 3AM when something fails?

Scope:

• Unhandled exceptions
• Silent failures
• Missing retries
• Resource leaks
• Race conditions
• Missing transactions
• Partial failures

This is your “will this wake somebody up at night?” audit.

Agent #3: Performance & Scalability

Persona: Staff Node.js Performance Engineer

Scope:

• N+1 queries
• Sequential awaits
• Event loop blockers
• Missing caches
• Excessive serialization
• Memory inefficiencies

One rule is critical here:

Every finding must estimate impact.

Don’t say:

This could be slow.

Say:

This endpoint executes 200 database queries instead of 1 under load.

Huge difference.

Agent #4: Platform & Observability

Persona: Staff Platform Engineer

Scope:

• Helmet
• Compression
• Body limits
• Rate limiting
• Graceful shutdown
• Health checks
• Structured logging
• Correlation IDs
• Metrics

Production-ready systems are debuggable systems.

These two belong together.

Agent #5: TypeScript & Code Health

Persona: Senior TypeScript Engineer

Scope:

• any usage and not types
• Unsafe assertions
• Null bugs
• Duplicate types
• Impossible states
• Weak interfaces

This one is intentionally last.
Not because it’s unimportant.
Because it’s usually the first thing that gets ignored when mixed with security findings.

Give it dedicated attention.

Why this works better

Three reasons:

1. Smaller scope = deeper analysis

An agent looking only for authorization bugs will trace every token validation path.
An agent looking for authorization bugs, race conditions and N+1 queries will skim all three.

2. Different mental models don’t mix well

Thinking like an attacker is different from thinking like an SRE.
Both are valuable.
Neither benefits from context switching.

3. The output becomes actionable

Nobody wants a 50-item audit report.
Five reports with 8 findings each are dramatically easier to assign and fix.
Security reviews security.
Platform reviews platform. Performance reviews performance.
That’s exactly how engineering organizations already operate.

How to run this in practice

1. Use identical output formats for all agents.
2. Give each agent only its own checklist.
3. Run them against the same commit.
4. Merge HIGH and CRITICAL findings into a single triage document.
5. Re-run only the agent that corresponds to the fixes you made.

One thing not to do

Don’t split by folders.

Don’t do:

• Agent A → routes/
• Agent B → services/
• Agent C → controllers/

That simply recreates the original problem. Every agent now needs all the expertise again.
Split by domain expertise, not by directory structure.

The takeaway

The giant audit prompt isn’t wrong. It’s just too broad. One agent doing five jobs becomes average at all five.
Five specialized agents become genuinely useful. That’s also how we build engineering organizations.
Maybe we should build our AI workflows the same way.

Rate this:

Migrating from Lovable: Steps to Self-Host Your App

Lovable is a remarkable product.
You describe what you want. It builds it. You ship in hours instead of weeks.
That’s genuinely impressive, and I’ve used it to launch things I would have otherwise shelved for “when I have more time.”

But “when I have more time” eventually arrives.

And when it does, you start asking different questions:

“What happens if they change pricing?”
“Can I run this on my own infrastructure?”
“Where exactly does my data live?”

Those aren’t paranoid questions. They’re the right questions.
This post is about answering them — practically, with actual steps you can follow.

Why Leave Lovable?

Before anything else: you might not need to.

Lovable is a solid platform. If your app is a side project, an internal tool, or an early-stage product with low traffic, staying there is probably the right call. The cost of self-hosting is real — you own the ops now.

But there are situations where moving makes clear sense:

Cost at scale
Lovable’s pricing is per-project and per-usage.
Once you’re past early stage, running your own stack on a VPS or cloud provider is often ~3–5x (or more) cheaper.

Data residency
Some industries (healthcare, finance, defense) require you to control where data lives.
“It’s on Lovable’s servers” isn’t an acceptable answer in those conversations.

Customization ceiling
Lovable generates clean React/Supabase apps, but it has opinions. When you need a specific architecture, edge functions, a custom auth flow, or native mobile builds outside their defaults — you hit the wall.

Ownership
At some point, the code is yours.
You should be able to run it. Anywhere.

What You’re Actually Working With

Lovable generates a specific stack.
Understanding it before you touch anything is important.

A typical Lovable export looks like this:

• Frontend: React (Vite), TypeScript, Tailwind CSS, shadcn/ui components
• Backend/DB: Supabase (Postgres, Auth, Storage, Edge Functions)
• Routing: React Router
• State/Fetching: TanStack Query, sometimes Zustand
• Deployment: Previously Lovable’s own hosting; they now push to GitHub and can connect to Netlify/Vercel

The code is real – It’s readable. There’s no magic proprietary runtime you need to reverse-engineer.
That’s the good news.

The less-good news:
Supabase is tightly integrated.
The app talks to a Supabase project by project URL and anon key. If you want to move away from Supabase (or self-host Supabase), that’s a bigger migration than just moving the frontend.

For most people: keep Supabase, move the frontend.
That’s the path of least resistance.

Step 1: Export Your Code

First things first.

Go to your Lovable project → click the GitHub button → connect your GitHub account → push the project.

You now have a real repository with real code. Clone it locally:

 git clone https://github.com/your-username/your-lovable-project.git  cd your-lovable-project  npm install 

Before you do anything else, make sure it runs locally:

 npm run dev 

If it opens in your browser and works: great. If it doesn’t: check your .env file (more on that in a moment).

Step 2: Understand Your Environment Variables

This is where most people get stuck.
Lovable injects environment variables automatically. When you run this yourself, you’re responsible for them.

Create a .env file in your project root:

 VITE_SUPABASE_URL=https://your-project-ref.supabase.co  VITE_SUPABASE_ANON_KEY=your-anon-key-here 

Find these in your Supabase dashboard → Project Settings → API.

One important thing: never commit your .env to git. Add it to .gitignore immediately if it isn’t already there.

 echo ".env" >> .gitignore 

For production deployments, you’ll set these as environment variables in your hosting provider’s dashboard — not as files checked into the repo.

Step 3: Build for Production

 npm run build 

This generates a dist/ folder. Everything in there is static — HTML, CSS, JavaScript bundles. No Node.js server required to serve it.

You can host this on:

• Vercel (easiest, free tier is generous)
• Netlify (similar to Vercel, excellent DX)
• Cloudflare Pages (fastest globally, very generous free tier)
• A plain VPS with Nginx (most control, most work)

My default recommendation:
1. Cloudflare Pages for public-facing apps
2. VPS + Nginx if you want full control and have ops comfort.

Step 4: Deploy to Cloudflare Pages (Recommended)

If you just want it running fast with zero infrastructure overhead:

1. Push your repo to GitHub (done in Step 1)
2. Go to Cloudflare Pages → Create Project → Connect GitHub
3. Select your repo
4. Set build settings:

• Build command: npm run build
• Build output directory: dist

1. Add your environment variables (VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY)
2. Deploy

Done.

Your app is live on a Cloudflare CDN edge network in ~2 minutes, with automatic deployments on every push to main.

Step 5: Deploy to a VPS (The “Real Self-Hosting” Path)

For maximum control, run it on your own server.
I recommend fly.io (so you don’t need to install/maintain anything – just build your webapp in docker) or Hetzner — the value is absurd compared to AWS or GCP for basic hosting needs.

Provision your server, then SSH in:

 ssh root@your-server-ip 

Install Nginx:

 apt update && apt install nginx -y 

Create your site directory and copy the build:

 mkdir -p /var/www/myapp  # From your local machine:  scp -r dist/* root@your-server-ip:/var/www/myapp/ 

Or better: set up a CI/CD pipeline that does this automatically on push.

Configure Nginx:

 server {      listen 80;      server_name yourdomain.com;      root /var/www/myapp;      index index.html;       # This is critical for React Router — all paths serve index.html      location / {          try_files $uri $uri/ /index.html;      }       # Cache static assets aggressively      location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2)$ {          expires 1y;          add_header Cache-Control "public, immutable";      }  } 

Save to /etc/nginx/sites-available/myapp, symlink it:

 ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/  nginx -t && systemctl reload nginx 

Add HTTPS with Let’s Encrypt:

 apt install certbot python3-certbot-nginx -y  certbot --nginx -d yourdomain.com 

Certbot auto-renews.
You’re done.

Step 6: The Native App Situation

If your Lovable app has a native mobile wrapper — this is where things get interesting.

Lovable has been expanding into native capabilities using Capacitor under the hood. If your project has native bindings, you’ll find a capacitor.config.ts in the project root.

The good news:
Capacitor is open-source and you own the workflow entirely.

For iOS:

 npm run build  npx cap sync ios  npx cap open ios 

This opens Xcode with your project. From there, you archive and submit to the App Store exactly like any other iOS app. You need an Apple Developer account ($99/year).

For Android:

 npm run build  npx cap sync android  npx cap open android 

This opens Android Studio. Build → Generate Signed Bundle/APK → distribute via Play Store or sideload directly.

The webview URL matters.

In development, Capacitor talks to localhost. In production, you need to point it at your live web app. Edit capacitor.config.ts:

 import { CapacitorConfig } from '@capacitor/cli';   const config: CapacitorConfig = {    appId: 'com.yourcompany.yourapp',    appName: 'Your App',    webDir: 'dist',    server: {      // Remove this for production — use bundled assets instead      // url: 'http://localhost:5173',      androidScheme: 'https'    }  };   export default config; 

For most native apps, you want the webDir approach — the built assets are bundled directly into the native app binary. This means offline support works and you don’t depend on your web server being up for the app to function.

Run npx cap sync after every build to keep the native project in sync with your web build.

Step 7: Handling Supabase at Scale

You moved the frontend. Supabase is still doing the backend work.

For most apps: that’s fine. Supabase is genuinely good infrastructure.

But if you want to self-host Supabase too (for compliance, cost, or curiosity), they publish an official Docker Compose setup:

 git clone --depth 1 https://github.com/supabase/supabase  cd supabase/docker  cp .env.example .env  # Edit .env with your secrets  docker compose up -d 

This runs the full Supabase stack — Postgres, GoTrue (auth), PostgREST, Realtime, Storage, and Studio — on your own hardware.

It’s more maintenance burden. But it’s also complete ownership.

My honest take: use Supabase managed unless you have a specific reason not to.
Their managed infrastructure is well-run and the pricing is reasonable until you’re at serious scale.

Step 8: Setting Up CI/CD So You Don’t Do This Manually Again

Manually copying files to a server is how you get paged at 2am because you forgot a step.

Here’s a minimal GitHub Actions workflow that builds and deploys on every push to main:

 # .github/workflows/deploy.yml  name: Deploy   on:    push:      branches: [main]   jobs:    deploy:      runs-on: ubuntu-latest      steps:        - uses: actions/checkout@v6         - name: Setup Node          uses: actions/setup-node@v6          with:            node-version: '24'            cache: 'npm'         - name: Install & Build          run: |            npm ci            npm run build          env:            VITE_SUPABASE_URL: ${{ secrets.VITE_SUPABASE_URL }}            VITE_SUPABASE_ANON_KEY: ${{ secrets.VITE_SUPABASE_ANON_KEY }}         - name: Deploy to Server          uses: appleboy/[email protected]          with:            host: ${{ secrets.SERVER_HOST }}            username: ${{ secrets.SERVER_USER }}            key: ${{ secrets.SSH_PRIVATE_KEY }}            source: "dist/*"            target: "/var/www/myapp"            strip_components: 1 

Add your secrets in GitHub → Settings → Secrets and variables → Actions.

Push to main. It deploys automatically.
That’s the whole loop.

The Checklist Before You Pull the Plug on Lovable

Don’t cancel your Lovable plan until you’ve verified all of this:

• [ ] App runs locally with npm run dev
• [ ] Production build succeeds with npm run build
• [ ] All environment variables are set correctly in production
• [ ] Supabase Row Level Security policies are configured (don’t rely on Lovable having set these correctly)
• [ ] Auth flows work end-to-end (sign up, sign in, sign out, password reset)
• [ ] Any storage/file uploads work against your Supabase bucket policies
• [ ] Edge functions (if any) are deployed to Supabase
• [ ] Custom domain is pointing to your new hosting
• [ ] HTTPS is working
• [ ] Native builds open and run correctly (iOS Simulator + Android Emulator at minimum)
• [ ] CI/CD pipeline deploys successfully from a test push

Run through this list twice.
Yep… On the second time you’ll catch something you missed.

What I’ve Learned From Doing This

Lovable is excellent for getting to a working product quickly.
Self-hosting is excellent for owning what you built.

These aren’t in conflict — they’re a sequence.

Build fast on Lovable.
Validate the idea.
Get real users.
Then, when the infrastructure costs start mattering or the compliance questions start arriving, migrate.

The migration is maybe 4–6 hours of focused work for a typical app.
That’s worth doing on a quiet Sunday, not during a crisis.

Do it before you need to.

Questions? Find me on GitHub

Rate this:

Migrating from Lovable: Steps to Self-Host Your App

Lovable is a remarkable product.
You describe what you want. It builds it. You ship in hours instead of weeks.
That’s genuinely impressive, and I’ve used it to launch things I would have otherwise shelved for “when I have more time.”

But “when I have more time” eventually arrives.

And when it does, you start asking different questions:

“What happens if they change pricing?”
“Can I run this on my own infrastructure?”
“Where exactly does my data live?”

Those aren’t paranoid questions. They’re the right questions.
This post is about answering them — practically, with actual steps you can follow.

Why Leave Lovable?

Before anything else: you might not need to.

Lovable is a solid platform. If your app is a side project, an internal tool, or an early-stage product with low traffic, staying there is probably the right call. The cost of self-hosting is real — you own the ops now.

But there are situations where moving makes clear sense:

Cost at scale
Lovable’s pricing is per-project and per-usage.
Once you’re past early stage, running your own stack on a VPS or cloud provider is often ~3–5x (or more) cheaper.

Data residency
Some industries (healthcare, finance, defense) require you to control where data lives.
“It’s on Lovable’s servers” isn’t an acceptable answer in those conversations.

Customization ceiling
Lovable generates clean React/Supabase apps, but it has opinions. When you need a specific architecture, edge functions, a custom auth flow, or native mobile builds outside their defaults — you hit the wall.

Ownership
At some point, the code is yours.
You should be able to run it. Anywhere.

What You’re Actually Working With

Lovable generates a specific stack.
Understanding it before you touch anything is important.

A typical Lovable export looks like this:

• Frontend: React (Vite), TypeScript, Tailwind CSS, shadcn/ui components
• Backend/DB: Supabase (Postgres, Auth, Storage, Edge Functions)
• Routing: React Router
• State/Fetching: TanStack Query, sometimes Zustand
• Deployment: Previously Lovable’s own hosting; they now push to GitHub and can connect to Netlify/Vercel

The code is real – It’s readable. There’s no magic proprietary runtime you need to reverse-engineer.
That’s the good news.

The less-good news:
Supabase is tightly integrated.
The app talks to a Supabase project by project URL and anon key. If you want to move away from Supabase (or self-host Supabase), that’s a bigger migration than just moving the frontend.

For most people: keep Supabase, move the frontend.
That’s the path of least resistance.

Step 1: Export Your Code

First things first.

Go to your Lovable project → click the GitHub button → connect your GitHub account → push the project.

You now have a real repository with real code. Clone it locally:

 git clone https://github.com/your-username/your-lovable-project.git  cd your-lovable-project  npm install 

Before you do anything else, make sure it runs locally:

 npm run dev 

If it opens in your browser and works: great. If it doesn’t: check your .env file (more on that in a moment).

Step 2: Understand Your Environment Variables

This is where most people get stuck.
Lovable injects environment variables automatically. When you run this yourself, you’re responsible for them.

Create a .env file in your project root:

 VITE_SUPABASE_URL=https://your-project-ref.supabase.co  VITE_SUPABASE_ANON_KEY=your-anon-key-here 

Find these in your Supabase dashboard → Project Settings → API.

One important thing: never commit your .env to git. Add it to .gitignore immediately if it isn’t already there.

 echo ".env" >> .gitignore 

For production deployments, you’ll set these as environment variables in your hosting provider’s dashboard — not as files checked into the repo.

Step 3: Build for Production

 npm run build 

This generates a dist/ folder. Everything in there is static — HTML, CSS, JavaScript bundles. No Node.js server required to serve it.

You can host this on:

• Vercel (easiest, free tier is generous)
• Netlify (similar to Vercel, excellent DX)
• Cloudflare Pages (fastest globally, very generous free tier)
• A plain VPS with Nginx (most control, most work)

My default recommendation:
1. Cloudflare Pages for public-facing apps
2. VPS + Nginx if you want full control and have ops comfort.

Step 4: Deploy to Cloudflare Pages (Recommended)

If you just want it running fast with zero infrastructure overhead:

1. Push your repo to GitHub (done in Step 1)
2. Go to Cloudflare Pages → Create Project → Connect GitHub
3. Select your repo
4. Set build settings:

• Build command: npm run build
• Build output directory: dist

1. Add your environment variables (VITE_SUPABASE_URL, VITE_SUPABASE_ANON_KEY)
2. Deploy

Done.

Your app is live on a Cloudflare CDN edge network in ~2 minutes, with automatic deployments on every push to main.

Step 5: Deploy to a VPS (The “Real Self-Hosting” Path)

For maximum control, run it on your own server.
I recommend fly.io (so you don’t need to install/maintain anything – just build your webapp in docker) or Hetzner — the value is absurd compared to AWS or GCP for basic hosting needs.

Provision your server, then SSH in:

 ssh root@your-server-ip 

Install Nginx:

 apt update && apt install nginx -y 

Create your site directory and copy the build:

 mkdir -p /var/www/myapp  # From your local machine:  scp -r dist/* root@your-server-ip:/var/www/myapp/ 

Or better: set up a CI/CD pipeline that does this automatically on push.

Configure Nginx:

 server {      listen 80;      server_name yourdomain.com;      root /var/www/myapp;      index index.html;       # This is critical for React Router — all paths serve index.html      location / {          try_files $uri $uri/ /index.html;      }       # Cache static assets aggressively      location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2)$ {          expires 1y;          add_header Cache-Control "public, immutable";      }  } 

Save to /etc/nginx/sites-available/myapp, symlink it:

 ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/  nginx -t && systemctl reload nginx 

Add HTTPS with Let’s Encrypt:

 apt install certbot python3-certbot-nginx -y  certbot --nginx -d yourdomain.com 

Certbot auto-renews.
You’re done.

Step 6: The Native App Situation

If your Lovable app has a native mobile wrapper — this is where things get interesting.

Lovable has been expanding into native capabilities using Capacitor under the hood. If your project has native bindings, you’ll find a capacitor.config.ts in the project root.

The good news:
Capacitor is open-source and you own the workflow entirely.

For iOS:

 npm run build  npx cap sync ios  npx cap open ios 

This opens Xcode with your project. From there, you archive and submit to the App Store exactly like any other iOS app. You need an Apple Developer account ($99/year).

For Android:

 npm run build  npx cap sync android  npx cap open android 

This opens Android Studio. Build → Generate Signed Bundle/APK → distribute via Play Store or sideload directly.

The webview URL matters.

In development, Capacitor talks to localhost. In production, you need to point it at your live web app. Edit capacitor.config.ts:

 import { CapacitorConfig } from '@capacitor/cli';   const config: CapacitorConfig = {    appId: 'com.yourcompany.yourapp',    appName: 'Your App',    webDir: 'dist',    server: {      // Remove this for production — use bundled assets instead      // url: 'http://localhost:5173',      androidScheme: 'https'    }  };   export default config; 

For most native apps, you want the webDir approach — the built assets are bundled directly into the native app binary. This means offline support works and you don’t depend on your web server being up for the app to function.

Run npx cap sync after every build to keep the native project in sync with your web build.

Step 7: Handling Supabase at Scale

You moved the frontend. Supabase is still doing the backend work.

For most apps: that’s fine. Supabase is genuinely good infrastructure.

But if you want to self-host Supabase too (for compliance, cost, or curiosity), they publish an official Docker Compose setup:

 git clone --depth 1 https://github.com/supabase/supabase  cd supabase/docker  cp .env.example .env  # Edit .env with your secrets  docker compose up -d 

This runs the full Supabase stack — Postgres, GoTrue (auth), PostgREST, Realtime, Storage, and Studio — on your own hardware.

It’s more maintenance burden. But it’s also complete ownership.

My honest take: use Supabase managed unless you have a specific reason not to.
Their managed infrastructure is well-run and the pricing is reasonable until you’re at serious scale.

Step 8: Setting Up CI/CD So You Don’t Do This Manually Again

Manually copying files to a server is how you get paged at 2am because you forgot a step.

Here’s a minimal GitHub Actions workflow that builds and deploys on every push to main:

 # .github/workflows/deploy.yml  name: Deploy   on:    push:      branches: [main]   jobs:    deploy:      runs-on: ubuntu-latest      steps:        - uses: actions/checkout@v6         - name: Setup Node          uses: actions/setup-node@v6          with:            node-version: '24'            cache: 'npm'         - name: Install & Build          run: |            npm ci            npm run build          env:            VITE_SUPABASE_URL: ${{ secrets.VITE_SUPABASE_URL }}            VITE_SUPABASE_ANON_KEY: ${{ secrets.VITE_SUPABASE_ANON_KEY }}         - name: Deploy to Server          uses: appleboy/[email protected]          with:            host: ${{ secrets.SERVER_HOST }}            username: ${{ secrets.SERVER_USER }}            key: ${{ secrets.SSH_PRIVATE_KEY }}            source: "dist/*"            target: "/var/www/myapp"            strip_components: 1 

Add your secrets in GitHub → Settings → Secrets and variables → Actions.

Push to main. It deploys automatically.
That’s the whole loop.

The Checklist Before You Pull the Plug on Lovable

Don’t cancel your Lovable plan until you’ve verified all of this:

• [ ] App runs locally with npm run dev
• [ ] Production build succeeds with npm run build
• [ ] All environment variables are set correctly in production
• [ ] Supabase Row Level Security policies are configured (don’t rely on Lovable having set these correctly)
• [ ] Auth flows work end-to-end (sign up, sign in, sign out, password reset)
• [ ] Any storage/file uploads work against your Supabase bucket policies
• [ ] Edge functions (if any) are deployed to Supabase
• [ ] Custom domain is pointing to your new hosting
• [ ] HTTPS is working
• [ ] Native builds open and run correctly (iOS Simulator + Android Emulator at minimum)
• [ ] CI/CD pipeline deploys successfully from a test push

Run through this list twice.
Yep… On the second time you’ll catch something you missed.

What I’ve Learned From Doing This

Lovable is excellent for getting to a working product quickly.
Self-hosting is excellent for owning what you built.

These aren’t in conflict — they’re a sequence.

Build fast on Lovable.
Validate the idea.
Get real users.
Then, when the infrastructure costs start mattering or the compliance questions start arriving, migrate.

The migration is maybe 4–6 hours of focused work for a typical app.
That’s worth doing on a quiet Sunday, not during a crisis.

Do it before you need to.

Questions? Find me on GitHub

Rate this:

Coding agents improve fast once they stop guessing how your repo works.

I wrote about why a small https://AGENTS.md matters more than most prompt tricks: scope, defaults, uncertainty, memory, and a template you can actually use. https://www.the-main-thread.com/p/coding-agent-operating-manual #AIAgents #SoftwareEngineering #DeveloperProductivity

Coding agents improve fast once they stop guessing how your repo works.

I wrote about why a small https://AGENTS.md matters more than most prompt tricks: scope, defaults, uncertainty, memory, and a template you can actually use. https://www.the-main-thread.com/p/coding-agent-operating-manual #AIAgents #SoftwareEngineering #DeveloperProductivity

The Engineering Leadership Crisis Nobody Talks About 🚨 #EngineeringLeadership #SoftwareEngineering #PlatformEngineering #TechLeadership #Microservices #SRE

https://atozofsoftwareengineering.blog/2026/05/19/the-engineering-leadership-crisis-nobody-talks-about-%f0%9f%9a%a8-engineeringleadership-softwareengineering-platformengineering-techleadership-microservices-sre/

The Engineering Leadership Crisis Nobody Talks About 🚨 #EngineeringLeadership #SoftwareEngineering #PlatformEngineering #TechLeadership #Microservices #SRE

https://atozofsoftwareengineering.blog/2026/05/19/the-engineering-leadership-crisis-nobody-talks-about-%f0%9f%9a%a8-engineeringleadership-softwareengineering-platformengineering-techleadership-microservices-sre/

⏰✨ Ah yes, because tracking how much time you waste in a terminal is the true pinnacle of developer productivity! Now you can finally ship that invoice without ever having to face the terrifying world outside the command line. Surely, a "closed ring" will magically fix your procrastination... or not. 🙈🔧
https://closedrings.sh/en #developerproductivity #timewasting #terminaltools #procrastinationcommandline #invoicetracking #HackerNews #ngated

⏰✨ Ah yes, because tracking how much time you waste in a terminal is the true pinnacle of developer productivity! Now you can finally ship that invoice without ever having to face the terrifying world outside the command line. Surely, a "closed ring" will magically fix your procrastination... or not. 🙈🔧
https://closedrings.sh/en #developerproductivity #timewasting #terminaltools #procrastinationcommandline #invoicetracking #HackerNews #ngated

The new 10x Engineer with AI

https://codeaholicguy.com/2026/05/13/the-new-10x-engineer-with-ai/

The new 10x Engineer with AI

https://codeaholicguy.com/2026/05/13/the-new-10x-engineer-with-ai/

Google Cloud Next 2026: 75% of Code Is Now AI-Generated — The Developer's Guide

At Google Cloud Next 2026, Sundar Pichai revealed that 75% of all new code at Google is now AI-generated and reviewed by engineers — up from 50% just six months ago. Here is wha...

https://wowhow.cloud/blogs/google-cloud-next-2026-75-percent-ai-generated-code-developer-guide

#wowhow #google #aicoding #developerproductivity

I use AI tools every day. They help. But I also feel the other side of it more now: more review, more supervision, more mental carry-over after the laptop is closed.

This piece is about that cost for senior Java developers and enterprise teams.

https://www.the-main-thread.com/p/ai-senior-java-developers-fatigue-productivity

#Java #EnterpriseJava #SoftwareEngineering #AI #DeveloperProductivity

This is possibly my favourite talk I've given in the last couple of years. It's about how to apply the stuff you've learnt at a conference (or through research) and how to convince your bosses that you need time to play.

#DeveloperProductivity

https://youtu.be/kSNwB5xilgQ?si=DFkZUttW4SltSN_o

#DeveloperProductivity isn’t just about faster builds or better tools - it’s about creating an environment where developers can do their best work.

In this #InfoQ video, Nicole Forsgren shares a practical blueprint to:
• Identify & remove the hidden friction slowing your team down
• Uncover obstacles
• Win stakeholder buy-in
• Scale DevEx improvements across your organization

🎬 Watch now | 📄 #transcript included: https://bit.ly/4tivSAP

#DevEx #BestPractices #Agile

🖥️ Ah, the thrilling world of font selection 🎮! Because why not turn the paralyzing indecision of choosing a coding font into a game 🙄? Try not to get too distracted by the riveting "LazyMono Industrial" and "Vibrant Ink," because clearly, this is the pinnacle of developer productivity tools. 🕹️🤦‍♂️
https://www.codingfont.com/ #fontselection #codingfonts #developerproductivity #gamification #LazyMonoVibrantInk #HackerNews #ngated

A Senior Engineer's Guide to Prompting AI for Real Code

https://techlife.blog/posts/a-senior-engineers-guide-to-prompting-ai-for-real-code/

#OpenAICodex #AICoding #PromptEngineering #SoftwareDevelopment #GPT5 #GitHubCopilot #AITools #DeveloperProductivity #CodeReview #AIAgents

What would your team do with 30% more time? By consolidating 12+ language ecosystems into one repository, the ActiveState Catalog helps DevSecOps teams reclaim engineering hours.
See how: https://www.activestate.com/resources/press-releases/activestate-unifies-79m-components-to-launch-worlds-largest-secure-open-source-catalog/?utm_source=twitter/x&utm_medium=organic_social&utm_campaign=fy26_q1_organic_social #DeveloperProductivity #SoftwareEngineering

🚀 Your CTO just mandated AI coding assistants for the whole engineering team but does it actually make you faster?

After months using Claude Code, GitHub Spec Kit, and other LLM workflows, we uncovered the real issues: from context rot to markdown mayhem.

AI feels magical… until specs meet user testing.

If you want the honest breakdown of what really works:

👉 Read the full analysis: https://squads.com/blog/ai-powered-development-beyond-the-hype

#DeveloperProductivity #AIInTech

RE: https://mastodon.social/@testlens/116012809176146110

Incredibly proud to finally make this project public. I've been working on this together with @marcphilipp and @jendrik and today we're launching the private beta program. Head to our website to reserve your seat!

#Java #Kotlin #Testing #DeveloperProductivity