If you sell Laravel applications, you’ve probably run into this problem before. A client purchases an affordable shared hosting plan, you upload the application, and suddenly, it crashes with a fatal error.
The reason is often simple: the server doesn’t have the required IonCube or SourceGuardian loader installed, and the hosting provider either refuses to install it or doesn’t offer support for it.
For years, the usual solution was to move the application to a VPS. But that isn’t always practical, especially when your clients want an affordable hosting plan that requires minimal maintenance.
Fortunately, loaderless PHP encoding offers another option.
In this guide, we’ll walk through a practical workflow for deploying protected Laravel applications on shared hosting platforms such as cPanel, Plesk, and other managed hosting environments, without relying on separately installed PHP loader extensions.
Step 1: Prepare Your Laravel Application
Before encoding your code, separate your proprietary application files from Laravel’s dependencies and runtime directories. This helps avoid compatibility issues during deployment.
Start by preparing a production build of your application. On your staging environment, run:
composer install --no-dev --optimize-autoloader
This installs the production dependencies and optimizes Composer’s autoloader.
Keep the following points in mind:
- Leave the
vendor/ directory unencoded. Laravel and Composer rely on their normal autoloading mechanisms, and encoding third-party dependencies can introduce compatibility issues.
- Do not encode the
storage/ directory. Laravel uses it for logs, cached files, sessions, and other runtime data.
- Leave
bootstrap/cache/ unencoded. Laravel needs to read and write cached configuration, route information, and other generated files as part of its normal operation.
The goal is to protect your own application code while leaving Laravel’s framework, dependencies, and runtime files working as expected.
Step 2: Choose the Right Encoding Engine
Traditional PHP encoders, such as IonCube and SourceGuardian, rely on server-side loaders to execute protected code. That can become a problem when your client’s hosting provider doesn’t support the required extension.
Loaderless encoding takes a different approach by allowing protected code to run without requiring a separately installed PHP loader. However, the exact implementation and compatibility depend on the encoder you choose.
For this workflow, PHPDEFENDER is one option to evaluate. Make sure the edition you select explicitly supports loaderless deployment.
Pay particular attention to how the encoder handles eval(), because shared hosting providers sometimes disable it for security reasons.
There are two approaches to consider:
- Eval-based encoding: May offer performance advantages in some implementations, but it requires
eval() to be available and permitted by the hosting environment.
- Non-Eval encoding: Designed for environments where
eval() cannot be used. This can be a better fit for restrictive shared hosting, although performance and compatibility depend on the specific encoder and application.
Before choosing an edition, verify its PHP version requirements, Laravel compatibility, and execution requirements against your client's hosting environment.
Step 3: Encode Your Application Code
Once your application is ready and you've selected a suitable encoder, you can start protecting your proprietary code.
Depending on your application, this may include files in app/, routes/, and config/, along with any custom code under database/ that you want to protect.
If you prefer a graphical interface, you can usually select the files and configure the encoding options directly. For automated builds or CI/CD pipelines, a command-line workflow may be more convenient.
If you are using the Enterprise CLI for automated builds, here are examples of the CLI commands used by different PHPDEFENDER encoding tools. The exact syntax and available options depend on the tool and edition you're using.
Activate your license:
.\climain.exe activate xxxx-xxxx-xxxx-xxxx-xxxx
Encode an individual PHP file using the PDW encoder:
.\pdwencode.exe -i "C:\path\to\index.php" -o "C:\path\to\encoded.php" -l disable -h "// Header line"
Encode a directory using the IEncoder tool:
.\iencoder.exe "C:\path\to\src" "C:\path\to\dest" disable p82 "with PHPpreamble"
These are separate examples for different tools, not steps that must all be executed in sequence. Replace the example paths and license key with your actual values, and confirm the supported options in the documentation for your specific encoder version.
Before encoding an entire Laravel application, test a small set of files and verify that the resulting code runs correctly in your target PHP environment. This can help identify compatibility issues before they affect your production deployment.
Step 4: Deploy to Shared Hosting
After encoding your application code, prepare the deployment package.
Upload the encoded application files along with the required unencoded Laravel files, including vendor/, environment configuration, and other files needed for production.
Before going live, check the following:
- Your server meets the application's PHP version and extension requirements.
- The
.env file contains the correct production settings and is not publicly accessible.
- The web server's document root points to Laravel's
public/ directory.
- The
storage/ and bootstrap/cache/ directories have the appropriate permissions.
Because loaderless encoding does not depend on a separately installed PHP loader, you can avoid that particular hosting requirement. However, loaderless encoding does not eliminate every deployment limitation. Your application must still be compatible with the server's PHP version, enabled extensions, filesystem permissions, and security restrictions.
Step 5: Configure Licensing (Optional, but Recommended)
If you distribute or sell protected Laravel applications, you may also want to control where and how they can be used.
Depending on the encoder's licensing features, you may be able to configure domain restrictions, expiration dates, or other licensing conditions.
For example, a domain restriction could limit an installation to clientdomain.com. If the application is copied to another domain, the licensing mechanism can prevent it from running as intended.
Some products also offer time-limited licenses for trial versions or subscription-based distribution.
Before relying on these features, check exactly how domain validation works, whether the application needs an internet connection for license checks, and what happens when a license expires or a server changes.
Final Thoughts
Deploying protected Laravel applications shouldn't automatically mean requiring every client to purchase a VPS.
When a client's shared hosting environment doesn't support traditional PHP loaders, loaderless encoding may provide a practical alternative. It can simplify deployment by removing the need for a separately installed loader, provided the encoder and application are compatible with the target server.
The key is to prepare your Laravel application carefully, choose the right encoding mode, leave framework dependencies and runtime files intact, and test everything in an environment that closely matches your client's hosting setup.
If you want to test this workflow, PHPDEFENDER offers a fully functional 15-day free trial. You can check the current trial terms on their website to confirm which editions and encoding modes are included before getting started.