Question about embedding a Laravel application in FrankenPHP without exposing source code

[dariogenova77]

Hello FrankenPHP Team,

first of all, thank you for your great work on FrankenPHP—it’s an exciting project and a pleasure to experiment with.

I have a question regarding application embedding.
Is there a way to bundle a Laravel application inside a FrankenPHP binary so that, at runtime, the application is not copied to a temporary directory on the host operating system’s filesystem, but instead only the paths that require read/write access are mounted or exposed?

The goal is to deploy the application on an appliance where the PHP source code should remain inaccessible, while still allowing Laravel to function normally (for example, for storage or cache directories).

Any guidance or best practices you can share would be greatly appreciated.

Thank you for your time and for all the work you put into FrankenPHP!

Best regards

[nickchomey]

I've also been curious about this, but for php in general and not just laravel. I suspect the answer is no

[dunglas]

With the current implementation, the source code is not encrypted and easily accessible.

I'm working on a commercial product allowing to obfuscate the code, but it's not ready yet.

[dariogenova77]

Hi Kevin,

thank you for your previous reply and for your work on FrankenPHP—it’s really impressive.

I have a follow-up question to clarify my use case.
At the moment, I don’t need the PHP sources to be encrypted or hidden;
my main goal is simply to deploy a Laravel application without leaving PHP files writable on the host filesystem, so that they cannot be altered once the appliance is delivered.

Is there a way to embed or package a Laravel app in FrankenPHP so that:

the PHP sources are available in read-only mode for execution,

only the few paths that Laravel truly needs for read/write (e.g. storage, bootstrap/cache, /tmp) are exposed as writable,

and no automatic extraction of the whole source tree into a temporary directory is required?

Even if the code remains visible, ensuring that it is immutable at runtime would already meet our needs.
Any guidance or recommended approach would be greatly appreciated.

Thanks again for your time and for pushing PHP forward!

Best regards

[TheArKaID]

Hi @dunglas, that is an interesting thing. Is there an estimate of when the product will be ready for testing?

[dariogenova77]

Hi Kevin, I’m very interested in your upcoming product. I’d be happy to help as a beta tester or share some insights about the use cases we’re dealing with in our appliances. We are currently evaluating FrankenPHP for our products and your solution sounds like it could be a great fit. Best, Dario Genova Fata informatica Il giorno gio 25 set 2025 alle 17:57 Kévin Dunglas ***@***.***> ha scritto:

…

With the current implementation, the source code is not encrypted and easily accessible. I'm working on a commercial product allowing to obfuscate the code, but it's not ready yet. — Reply to this email directly, view it on GitHub <#1898 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BPVO77DEFMU4Z3KWIVUNEW33UQGF3AVCNFSM6AAAAACHP6FN7OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINJRGMYDQOI> . You are receiving this because you authored the thread.Message ID: ***@***.***>