# How to Deploy Laravel on Render: Step-by-Step Guide

> Learn how to deploy Laravel on Render step by step: build script, PostgreSQL, environment variables, queue workers, common errors, and production limits.
- **Author**: rohan-kulkarni
- **Published**: 2026-05-22
- **Modified**: 2026-05-22
- **Category**: Deployment Guides
- **URL**: https://kuberns.com/blogs/deploy-laravel-on-render/

---

You can deploy a Laravel app on Render. The process involves creating a Web Service, writing a build script that runs your Artisan commands, connecting a PostgreSQL database, and setting your production environment variables. That is the short version.

The longer version is that Laravel has a production checklist that Render does not automate for you. PHP extension configuration, migrations, storage linking, queue workers, and the scheduler all need to be wired up manually. Most guides skip these parts, and that is exactly where first deploys fail.

This guide covers every step in plain language, the errors you will hit and how to fix them, and where Render starts to show its limits for a full Laravel setup.

If you want a broader look at how Render works before deploying a specific framework, start here: [How to Deploy on Render: Complete Guide 2026](https://kuberns.com/blogs/how-to-deploy-on-render/)

## What You Need Before Deploying Laravel on Render

![What You Need Before Deploying Laravel on Render](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/deploy-laravel-on-render-prerequisites.png)

Before you touch the Render dashboard, four things need to be in order. Missing any of them is the most common reason a first deploy fails or the app crashes immediately after going live.

**Your composer.json and composer.lock must be committed.** Render runs Composer during your build to install dependencies. Never commit the vendor folder itself. Commit the lock file so Render installs exact versions.

**Your app must run cleanly in a local environment.** Run `php artisan serve` and confirm the app loads without errors before deploying. Debugging a broken app through Render's build logs is much harder than fixing it locally first.

**Your GitHub repository must be connected to Render.** Render deploys directly from GitHub on every push. Make sure your code is pushed and your `.env` file is in `.gitignore` and never committed.

**Your production environment variable values must be ready.** You will need your database credentials, a production `APP_KEY`, your production `APP_URL`, and any third-party keys your app uses. Collect these before you start so you are not hunting for them mid-setup.

## How to Deploy Laravel on Render: Step by Step

![How to Deploy Laravel on Render Step by Step](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/deploy-laravel-on-render-steps.png)

### Step 1: Create a Web Service on Render

Log in to your Render dashboard and click **New**, then select **Web Service**. Connect your GitHub account if you have not already, then select the repository that contains your Laravel project. Choose the branch you want to deploy from, typically `main`.

Render will ask for your runtime environment. Select **PHP** from the list.

### Step 2: Set Your Build Script and Start Command

This is the step most guides gloss over, and it is where most Laravel deploys break.

Render runs a build command once every time you deploy. This is where you tell Render how to prepare your app. For a Laravel project, that means installing dependencies and running the Artisan commands that Laravel needs before it can handle requests.

In the **Build Command** field, enter a script that does the following in sequence: installs Composer dependencies without development packages, caches your configuration and routes so they load faster in production, links your storage directory so uploaded files are accessible, and runs your database migrations so the schema is always up to date.

A clean build command for Laravel looks like this:

```bash
composer install --no-dev --optimize-autoloader
php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan storage:link
php artisan migrate --force
```

Each line does one specific thing. The Composer install brings in your production dependencies. The three cache commands pre-compile your config, routes, and views so your app does not re-read files on every request. The storage link makes your `storage/app/public` folder accessible at the `public/storage` URL. The migrate command updates your database schema on every deploy.

In the **Start Command** field, enter the command Render uses to actually run your app:

```bash
php artisan serve --host=0.0.0.0 --port=$PORT
```

The `$PORT` variable is important. Render assigns a dynamic port to your container. If you hardcode a port number, Render cannot route traffic to your app and you get a 502 error on every request.

You can also set a `PHP_VERSION` environment variable to pin a specific PHP version for your build.

### Step 3: Set Up PostgreSQL on Render

Laravel needs a database. In your Render dashboard, click **New** and select **PostgreSQL**. Give the instance a name and choose a plan. The free plan is available but has a hard limit worth knowing about upfront: Render permanently deletes free PostgreSQL instances after 90 days, including all data. More on that later.

Once the database is created and its status shows **Available**, scroll down on the database detail page and copy the **Internal Database URL**. This is the connection string your Laravel app will use to connect to the database within Render's internal network.

For a full breakdown of what Render's PostgreSQL plans cost and what the limits are at each tier, see: [Render PostgreSQL: Setup, Pricing and Limits](https://kuberns.com/blogs/render-postgres-pricing-setup-limits/)

> **Is Render's free database actually safe for your production app?** Read why the 90-day limit is a bigger risk than it looks: [Render PostgreSQL: Setup, Pricing and Limits](https://kuberns.com/blogs/render-postgres-pricing-setup-limits/)

### Step 4: Set Environment Variables

In your Render Web Service settings, go to the **Environment** tab and add your production variables one by one.

The variables your Laravel app needs at minimum:

- `APP_KEY` generate this locally by running `php artisan key:generate --show` and copying the output
- `APP_ENV` set this to `production`
- `APP_DEBUG` set this to `false`
- `APP_URL` your full production URL including `https://`
- `DB_CONNECTION` set to `pgsql`
- `DATABASE_URL` paste the Internal Database URL you copied from your PostgreSQL service

Laravel reads `DATABASE_URL` automatically when `DB_CONNECTION` is set to `pgsql`. You do not need to set `DB_HOST`, `DB_PORT`, `DB_DATABASE`, and `DB_USERNAME` separately if you use the full connection string.

Never store these values in your repository. Render encrypts environment variables at rest and they never appear in build logs.

### Step 5: Add a Custom Domain

In your Web Service settings, go to the **Custom Domains** tab and add your domain. Render provides a CNAME record to add to your DNS provider. Once DNS propagates, Render automatically provisions a TLS certificate. Your Laravel app is live on your domain with HTTPS from that point.

## Common Errors When Deploying Laravel on Render

![Common Errors When Deploying Laravel on Render](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/deploy-laravel-on-render-errors.png)

Even with the steps above followed correctly, a few errors show up consistently in first deploys.

| Error | What Causes It | How to Fix It |
|---|---|---|
| 500 on every page | Missing or incorrect `APP_KEY` | Generate the key locally and add it as an environment variable |
| Routes return 404 | Config not cached | Add `php artisan config:cache` and `php artisan route:cache` to your build script |
| Database connection refused | Wrong `DATABASE_URL` format | Use the Internal Database URL from your Render PostgreSQL service, not the external URL |
| Storage URLs returning 404 | Storage symlink not created | Add `php artisan storage:link` to your build script |
| 502 Bad Gateway on every request | App not binding to the correct port | Use `--port=$PORT` in your start command |
| Migrations not running | Not included in build script | Add `php artisan migrate --force` at the end of your build script |
| Build fails on Composer step | `vendor/` committed or `composer.lock` missing | Remove `vendor/` from the repo, commit `composer.lock`, and redeploy |

If your error is not in this table, the Render build log is your best starting point. Each step in the build script outputs its result, so a failure almost always points to the exact command that broke.

## Laravel on Render: What Does Not Work Out of the Box

![Laravel on Render What Does Not Work Out of the Box](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/deploy-laravel-on-render-limits.png)

The steps above get a basic Laravel app running. But Laravel is not a basic framework, and Render is a general-purpose platform that does not know anything specific about Laravel's production requirements. Here is what you will need to wire up yourself.

**Queue workers are a separate service.** Laravel's queue system needs a long-running process that processes jobs from the queue. On Render, that means creating a separate Background Worker service alongside your web service. It does not share configuration with your web service by default, so you need to duplicate your environment variables. On the free tier, background workers spin down after inactivity, which means queued jobs sit unprocessed until the worker wakes up.

**Laravel Scheduler needs its own cron service.** The scheduler runs via a cron entry that calls `php artisan schedule:run` every minute. Render does not add this automatically. You need to create a separate Cron Job service in your dashboard or `render.yaml` file. That is a third service to manage alongside your web service and queue worker.

**The free PostgreSQL instance expires.** Render's free tier PostgreSQL database is permanently deleted after 90 days, including all data. Render's own documentation recommends not using free instances for production. If you are building anything that needs to persist data beyond three months, you need a paid database plan.

**Cold starts slow down your first request.** On the free tier, Render spins down your web service after 15 minutes of inactivity. The next request that hits the app waits 30 to 60 seconds for the service to wake up. For a Laravel app serving real users, that wait is noticeable and not acceptable for production traffic.

**File uploads do not survive redeploys.** Render's free tier does not provide a persistent disk. Every time you push new code and trigger a deploy, the container is replaced and any files uploaded to local storage are gone. Laravel apps that handle file uploads need either Render's paid disk option or an external service like S3.

**No shell access on the free plan.** If something breaks in production, you cannot SSH into the running container on a free Render plan to inspect what is happening. Debugging is limited to what appears in the logs.

For a broader look at what Render costs at each plan and when upgrading starts to make sense, see: [Render Pricing Explained](https://kuberns.com/blogs/render-pricing/)

> **Paying for Render's higher tiers? Here is exactly what you get and where the pricing jumps:** [Render Pricing Explained](https://kuberns.com/blogs/render-pricing/)

## The Faster Way to Deploy Laravel is on Kuberns

![The Faster Way to Deploy Laravel is on Kuberns](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/kuberns-home-page-new.png)

Render can run Laravel, but it treats Laravel like any other web process. Every production requirement that Laravel specifically needs, from Artisan commands to queue workers to the scheduler, is something you configure manually. That is fine if you enjoy infrastructure work. It is friction if you just want your app live.

[Kuberns](https://kuberns.com) is an agentic AI cloud platform built specifically for applications like Laravel. Instead of asking you to write build scripts and manage separate services, the AI reads your Laravel repository, detects the framework, and runs everything your app needs on every deploy automatically.

On Kuberns, you do not write a build script. The AI runs Composer, executes the Artisan optimization commands, runs migrations, creates the storage link, and starts your app. Queue workers run as managed processes without a separate service or Supervisor configuration. The scheduler runs without a cron entry. Every deploy triggers the full sequence automatically.

[See what a one-click Laravel deployment actually looks like on Kuberns](https://kuberns.com/services/laravel)

### Render vs Kuberns for Laravel

| Laravel requirement | Render | Kuberns |
|---|---|---|
| PHP setup | Manual environment config | Auto-detected by AI |
| Composer install | Manual build script | Automated on every deploy |
| Artisan cache commands | Manual build script | Automated on every deploy |
| Database migrations | Manual build script | Automated on every deploy |
| Storage link | Manual build script | Automated on every deploy |
| Queue workers | Separate paid service | Auto-managed, no extra service |
| Laravel Scheduler | Separate cron service | Auto-managed, no cron entry |
| Cold starts on free tier | Yes, 30 to 60 seconds | No cold starts |
| Free database expiry | 90 days then deleted | No expiry |
| File upload persistence | Paid disk required | Included |

**Build and deploy with AI now** at [https://dashboard.kuberns.com](https://dashboard.kuberns.com)

If you are evaluating Render alongside other platforms before deciding, this comparison covers the options side by side: [Best Render Alternatives for Developers](https://kuberns.com/blogs/best-render-alternatives/)

> **Not sure if Render is the right platform for your Laravel app? See how it stacks up against the alternatives:** [Best Render Alternatives for Developers](https://kuberns.com/blogs/best-render-alternatives/)

## Conclusion

Deploying Laravel on Render works once you understand what Render automates and what it does not. The core process is straightforward: create a Web Service, write a build script that runs your Artisan commands, set up a PostgreSQL database, and add your environment variables. That gets a basic Laravel app live.

Where the setup gets complex is everything beyond the basics. Queue workers need a separate service. The scheduler needs its own cron job. The free database disappears after 90 days. File uploads require a paid disk. Cold starts slow down the free tier. Each of these is solvable, but each one is something you configure and manage yourself.

If you want a platform that handles the full Laravel production checklist without configuration files, Kuberns automates every step that Render leaves manual. For a faster path to a production-ready Laravel app, that is where the difference shows.

[The fastest way to deploy a Laravel app on Kuberns](https://kuberns.com/blogs/deploy-laravel-app/)

## Frequently Asked Questions

### Does Render support PHP and Laravel natively?

Render does not have a native PHP buildpack. You deploy Laravel by selecting a PHP environment, writing a build script that runs Composer and Artisan commands, and using a start command that binds to the port Render assigns. It works but requires manual setup compared to platforms with native Laravel support.

### How do I run php artisan migrate automatically on Render?

Add the migrate command at the end of your build script. Render runs the build script once per deploy, so migrations run automatically every time you push code. Use the `--force` flag so the command runs without prompting for confirmation in a non-interactive environment.

### Can I run Laravel queue workers on Render?

Yes, but you need to create a separate Background Worker service on Render alongside your web service. The worker service runs the `queue:work` command continuously. On Render's free tier, background workers spin down after inactivity, which causes queued jobs to pile up. A paid plan is required for reliable queue processing.

### Does Laravel Scheduler work on Render?

Not automatically. Laravel Scheduler needs a cron entry that calls `php artisan schedule:run` every minute. On Render, you need to create a separate Cron Job service in your dashboard or `render.yaml` to trigger this command. It works but adds an extra service to manage.

### How do I set APP_KEY for Laravel on Render?

Generate a key locally by running `php artisan key:generate --show` in your project directory. Copy the output, which starts with `base64:`, and paste it as the value for the `APP_KEY` environment variable in your Render service dashboard under the Environment tab.

### What happens to my Render PostgreSQL database after 90 days?

Render permanently deletes free PostgreSQL instances after 90 days, including all data. Render's own documentation advises against using free database instances for production. If you are building anything beyond a prototype, budget for a paid PostgreSQL plan from the start.

### Is Render free for Laravel apps?

Render's free tier can run a Laravel web service, but with significant limitations. The service sleeps after 15 minutes of inactivity and takes 30 to 60 seconds to wake up. The free PostgreSQL instance is deleted after 90 days. File uploads and storage are lost on every redeploy. For a real production Laravel app, the free tier is not suitable.

---
- [More Deployment Guides articles](https://kuberns.com/blogs/category/deployment-guides/1/)
- [All articles](https://kuberns.com/blogs/)