Skip to content

Knowledgebase

Deploying Laravel with a private application root

development

A Laravel release contains private configuration, application code and dependencies as well as public assets. The website must serve the public directory while keeping the rest of the project outside direct web access.

Check access and requirements

Confirm the PHP version and extensions required by your Laravel branch, Composer availability, database access and the ability to select a document root. A plan that only runs ordinary PHP files may not support persistent workers or every Laravel service.

01 Deploy Laravel with a private application root

  1. Create a separate release directory and upload the reviewed application, including its dependency lock file. Exclude local secrets, development logs and unneeded test data.

  2. Install the locked production dependencies using the matching PHP executable. Create production configuration from your own environment values and keep debug output disabled.

  3. Point the domain document root to the project public directory. If the panel cannot do this, ask us for an appropriate configuration before publishing. Moving the front controller into the project root can expose private files.

  4. Give the application process the access it needs to storage and bootstrap/cache. Configure the database and any scheduled work separately, then build the required frontend assets.

  5. Build the framework caches for the release and start it through the supported web stack. Record the release identifier and retain a tested previous release.

02 Example: map a Laravel domain to its public entry point

For a release stored in /home/ACCOUNT/apps/booking, select the public directory as the domain’s document root. These example form values describe the mapping; they do not create directories or grant access permissions automatically.

Code or configuration example
Domain: booking.example.com
Application root: /home/ACCOUNT/apps/booking
Document root: /home/ACCOUNT/apps/booking/public
Front controller: public/index.php
Private writable paths: storage and bootstrap/cache

Keep .env, application code and Composer dependencies outside the served root. Grant the application user only the required access to its writable directories through the supported hosting controls. Confirm the approved release includes the built frontend assets and a correctly configured application key.

Expected result: The homepage and a named application route both work. A direct request to /.env cannot return credentials, and logs are written privately. Correct a mapping error instead of moving Laravel’s front controller into the private application root.

Confirm the expected result

Open a public page, submit a harmless form and check an authenticated page. Requests for /.env and private project files must not return their contents. Review the private application log.

Resolve setup problems

If every route returns 404, check the document root and front-controller rewrite configuration. A 500 response needs the corresponding application or PHP log entry before changing dependencies.

A common question

Can I run every Laravel feature on shared hosting?

Only when the account supplies its required runtime and process capabilities. Queues, WebSockets and long-running application servers may require a different plan even when normal web requests work.

Sources and further reading

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support