Question 1

Can I publish multiple projects at the same time?

Accepted Answer

Yes, each project can be published independently. Publishing one project doesn't affect others. Each project gets its own Lovable subdomain or custom domain.

Question 2

My deployment keeps failing.

Accepted Answer

Check for build errors in your project—the AI may have introduced code issues. Try reverting to a recent working version and publishing that. Review error messages in the deployment logs. If you can't resolve it, share the error details with support.

Question 3

Publishing is stuck on 'uploading' or 'checking.'

Accepted Answer

Wait a few minutes—large projects can take time to upload. If it's stuck for more than 10 minutes, refresh the page and try again. Contact support if the issue persists.

Question 4

The publish button is stuck or not responding.

Accepted Answer

Try refreshing the page and clicking 'Publish' again. Clear your browser cache or switch browsers. Check if your project has build errors by reviewing the latest chat messages. If the issue persists, contact support with your project URL.

Question 5

Can I restrict who can access my published app?

Accepted Answer

By default, published apps are public. To restrict access, add authentication (login page) using Supabase email/password or Google OAuth. Business/Enterprise plans offer workspace-only publishing—restrict access to workspace members only. Alternatively, deploy to a custom domain and use network-level access controls outside Lovable.

Question 6

Can I see analytics for my published projects?

Accepted Answer

Lovable's built-in analytics are limited. For detailed analytics, integrate Google Analytics, Mixpanel, or similar via a prompt: 'Add Google Analytics.' Lovable will add the tracking code. Project Settings shows basic info like project URL and visibility, but not traffic metrics.

Question 7

Can I use the Security view for published projects?

Accepted Answer

Yes, you can use the Security center to review security findings for any project before or after publishing. Security issues exist in your code regardless of deployment status. Address critical findings before publishing to a production domain. The Security center helps you maintain code quality at any stage.

Question 8

Why can't I publish my Lovable project?

Accepted Answer

Common reasons: (1) Syntax errors in your code—check the Cloud tab → Logs. (2) Missing required fields or unresolved dependencies. (3) Database connection issues if using Supabase. (4) Quota limits on free/Pro plans. Use the 'Try to fix' button (FREE, no credits) to scan logs and attempt a quick fix, which resolves ~60% of simple issues. For complex issues, contact support@lovable.dev.

Question 9

[Deployment] Why doesn't Lovable tell users that sites aren't server-rendered?

Accepted Answer

Lovable generates React SPAs (Single Page Applications) with client-side rendering by default. For SEO, enable prerendering so crawlers receive fully rendered HTML. You can also create a sitemap.xml and submit to Google Search Console for better discoverability.

Question 10

Does publishing expose my project and code?

Accepted Answer

No. Publishing only makes your website public at a URL. Your Lovable project remains private—only invited collaborators can access it. Your code is protected unless you explicitly sync to GitHub or download it. API keys and secrets are never included in exports. Keep sensitive keys in Cloud → Secrets or Supabase Edge Function secrets.

Question 11

Does publishing my project give everyone access to my project and code?

Accepted Answer

Publishing your app does NOT give access to your Lovable project or code. It only publishes the live website. Your Lovable project remains private—only invited collaborators can edit it. Your code is also protected unless you explicitly sync it to GitHub or export it. Published URLs are public, but the codebase stays in Lovable.

Question 12

Example: Manual Docker deployment

Accepted Answer

Export code from GitHub, create a Dockerfile (multi-stage: build React app, serve with lightweight server). Build the image locally with `docker build`, test with `docker run`, then push to Docker Hub or a private registry. Deploy to your server (VPS, Kubernetes, etc.) by pulling and running the image. This gives you full control over the runtime environment.

Question 13

Example: Manual VM or static server deployment

Accepted Answer

Export code from GitHub, run `npm run build` to generate static files. SSH into your server and copy the `/dist` folder to your web server's document root (e.g., /var/www/html). Configure your web server (nginx, Apache) to serve the files and handle routing properly. This simple approach works well for apps without complex server-side logic.

Question 14

How do I publish my project?

Accepted Answer

Click 'Publish' at the top of the editor. Choose between a Lovable subdomain (yourapp.lovable.app) or custom domain. To update a published site, click Publish → Update. Your changes go live immediately.

Question 15

How to publish a Lovable app to the App Store

Accepted Answer

Lovable publishes to the web (via Lovable subdomains or custom domains), not natively to the App Store. To get your Lovable app on the App Store, export the code and wrap it with a tool like Median.co or Capacitor to turn it into a native iOS app, then submit to the App Store following Apple's guidelines.

Question 16

What are the main CSR SEO limitations, and how do I work around them?

Accepted Answer

CSR limitations: crawlers may see empty HTML (hurts SEO), slower initial load (harms Core Web Vitals and rankings). Work around by: 1) Enable prerendering for static pages, 2) Use dynamic meta tags that render server-side, 3) Add structured data in the HTML ``, 4) Optimize JavaScript bundle size, 5) Use lazy loading for images. Prerendering is the simplest solution.

Question 17

What is prerendering, and when do I need it?

Accepted Answer

Prerendering converts your dynamic React app into static HTML pages at build time, so crawlers see fully-rendered content instead of empty divs. It's essential for SEO since Lovable uses client-side rendering (CSR) by default. Enable prerendering if you have static or semi-static pages (blogs, marketing sites). For fully dynamic apps (dashboards, real-time data), CSR is fine.

Question 18

When is Lovable a good fit for SEO and GEO, and when should I consider SSR or prerendering?

Accepted Answer

Lovable (React CSR) is great for dynamic, interactive apps. For SEO-critical sites (blogs, product pages, content marketing), enable prerendering to generate static HTML that crawlers see immediately. Server-side rendering (SSR) is harder with Lovable's current setup; prerendering is the simpler solution. For purely dynamic content (user dashboards, personalized data), CSR with SSR proxies may be needed.

Question 19

My published site is down and users can't access it.

Accepted Answer

Check status.lovable.dev for any service incidents. Verify your domain's DNS records are still pointing to Lovable. Try accessing your Lovable preview URL—if that works, the issue is domain-related. Contact support immediately for production issues.

Question 20

Will my site go down if my subscription expires?

Accepted Answer

Your published site may go offline after your subscription ends. Resubscribe to restore it. Your project code and data are preserved regardless of subscription status.

Publishing & Deployment

Can't Publish/Deploy

Deployment Architecture

How to Publish

Rendering & SSR

Self-Hosting & Deployment

Site Updates

Pronto(a) para criar?