Fly-Laravel was created by Fly.io and is a quick way to get a Laravel app running on Fly.io. It was built using Laravel Zero.

Fly-Laravel assumes that you have flyctl installed, and that you have it connected to your Fly.io account. If you need help with this, check out https://fly.io/docs/speedrun/.

These commands will help you set up apps on Fly.io. Remember that running these apps can cost money!

You can find more about Fly.io’s free allowance and pricing here.

Run composer require fly-apps/fly-laravel to install the latest version.

By default, commands are invoked using the vendor/bin/fly-laravel script. To avoid have to type all that for ecery command, you may configure a shell alias:

alias fly-laravel='vendor/bin/fly-laravel'

To make sure this is always available, you may add this to your shell configuration file in your home directory, such as ~/.zshrc or ~/.bashrc, and then restart your shell.

With this package, you can spin up Laravel, MySQL and/or Redis apps on Fly.io . There are two commands for every type of app: launch and deploy.

• Launch will create a new application on Fly.io in the organization you choose.
• Deploy will (re)deploy the app. This will update the app you’ve already created with launch.

• You have an account on Fly.io
• You have created an organization on Fly.io
• You have installed the flyctl agent.

Run fly-laravel launch to create a new Laravel application. You will be able to pick the name, what organization to deploy in and what extra services you want to set up.

• App name: What the app on Fly.io will be called. This can only contain alphanumeric characters and hyphens, for DNS reasons.
• Primary Region: The primary region to deploy your app in. You should pick the region closest to your users. You can always add more regions, as specified in the Scaling Documentation
• Organization: On Fly.io, apps can be grouped into organizations. Organizations are a great way to divide up apps, share access with team members and manage billing. If there’s only one organization available we’ll auto-select that one.
• Services: you can pick if you want to run cron or a queue worker in the app. This will create a process group for each extra service, to scale independently.

To set up the app, a number of steps will occur to set up a basic Laravel app:

• The locally installed Node and PHP versions are detected
• The fly.toml app configuration file is generated. If you want to make changes to your app later on, this is where to do it.
• Some folders and files are copied over, most notably the Dockerfile.
• A randomly generated APP_KEY will be set as a secret on your app.

A note on the configured SESSION_DRIVER in the fly.toml file:

• By default, your Laravel app will be configured with Cookie-based session storage. This allows sessions to work across multiple instances of your web app without the need of an external session service like Redis to make session data available to all the instances. Of course Cookie-based session storage has limits on how much session data it can store, so you might want to consider replacing this to allow storage of larger data.

After set up, your app will be ready to deploy! In your project root, a .fly folder will be added alongside a Dockerfile and a fly.toml file.

When launching databases you will need to deploy again so launch those before deploying the laravel app.

Run fly-laravel deploy to deploy your Laravel app. This will update the running app (if any) to include your latest changes. Add the --open flag to open the app in your browser when it has been deployed.

Run fly-laravel launch:mysql to create a new MySQL application. You will be able to pick the app name, what organization to deploy in, the MySQL username and the volume name. If a Laravel app is detected, you can opt to use the same organization and primary region.

• App Name: What the app on Fly.io will be called. This can only contain alphanumeric characters and hyphens, for DNS reasons. By default, [laravel app name]-db will be proposed as the app name.
• Organization: On Fly.io, apps can be grouped into organizations. Organizations are a great way to divide up apps, share access with team members and manage billing. If there’s only one organization available we’ll auto-select that one.
• Primary Region: The primary region to deploy your app in. You should pick the region closest to your users. You can always add more regions, as specified in the Scaling Documentation
• Volume Name: For data persistence, a volume will be needed for database applications. If there’s a volume with this name available, we’ll use that. If no volume with this name can be found, a 1GB volume will be created on deploy. More about volumes here: Volume Documentation.

Some notes when launching a MySQL database:

• During the launch, some environment variables will be updated in the fly.toml configuration of the Laravel app. Redeploying the Laravel app will be necessary to reflect these changes.
• The DB_CONNECTION env var in fly.toml will be set to ‘mysql’
• On deploy, a small scale machine will be provisioned with a 1x shared CPU and 256Mb of memory. Consider scaling up the database for better performance.
• By default, the innodb buffer pool size will be set to 64MB. Consider optimizing this based on your performance requirements. You can find this in .fly/mysql/fly.toml, in the [processes] section.
• For the networking to work properly, the Laravel app and MySQL app should be in the same organization.

Run fly-laravel deploy:mysql to deploy the MySQL application. After the deployment we’ll run a quick check of the machine resources, and show a warning if the memory is smaller than 1GB.

Run fly-laravel launch:redis to launch a Redis application. You will be able to pick the app name, what organization to deploy in and the volume name. If a Laravel app is detected, you can opt to use the same organization and primary region.

• App Name: What the app on Fly.io will be called. This can only contain alphanumeric characters and hyphens, for DNS reasons. By default, [laravel app name]-db will be proposed as the app name.
• Organization: On Fly.io, apps can be grouped into organizations. Organizations are a great way to divide up apps, share access with team members and manage billing. If there’s only one organization available we’ll auto-select that one.
• Primary Region: The primary region to deploy your app in. You should pick the region closest to your users. You can always add more regions, as specified in the Scaling Documentation
• Volume Name: For data persistence, a volume will be needed for database applications. If there’s a volume with this name available, we’ll use that. If no volume with this name can be found, a 1GB volume will be created on deploy. More about volumes here: Volume Documentation.

Some notes when launching a Redis application:

• During the launch, some Laravel environment variables will be updated in its fly.toml configuration. Redeploying the Laravel app will be necessary to reflect these changes.
• The CACHE_DRIVER and SESSION_DRIVER env vars in fly.toml will be set to ‘redis’
• On deploy, a small scale machine will be provisioned with a 1x shared CPU and 256Mb of memory. Consider scaling up the database for better performance.
• For the networking to work properly, the Laravel app and Redis app should be in the same organization.

Run fly-laravel deploy:redis to deploy the Redis application. After the deployment we’ll run a quick check of the machine resources, and show a warning if the memory is smaller than 1GB.

For more information about fly.io, check out the Fly.io Docs.

For more Laravel-related content, check out the Laravel-Bytes blog.

Fly-Laravel is an open-source software licensed under the MIT license.

The goal of this open source package is security through obscurity.

It aims to offer an alternative to delivering your closed source projects in plaintext. Instead, you can opt to deliver them in ciphertext (encrypted), alongside a binary PHP extension which will decrypt them on the fly.

This package uses symmetric encryption, therefore the AES-256 key (which is only known to you as the developer), can be unique per project and/or release. To avoid being detected by hex editors (e.g. Hex Fiend) and the strings command, the key is stored within the binary as an XOR cipher, split into 32 parts. Additionally, the XOR key is also split into 32 parts. All 64 key parts are then shuffled together along with 64 random key parts (128 parts in total) to ensure that the AES-256 and XOR key parts never appear in the same place twice.

If you search for an obfuscation package, there is almost always a complimentary deobfuscation package available (written by someone else), which renders the original package obsolete (unfortunately). On the other hand, AES-256 encryption hasn’t been broken (yet)!

That being said, I would certainly consider obfuscation as a compliment to encryption. If your source code is obfuscated first (before encryption) and someone tries to reverse engineer your project by looking at the opcodes and stepping through it, it would be much more difficult to understand.

Typically, obfuscation focuses on altering the execution flow of your source code, combined with the scrambling of the names of your classes, methods, functions, variables and string literals. Because obfuscation essentially rewrites your code, it inevitably comes with a few “gotchas” along the way. Encryption, on the other hand, keeps your code intact (exactly as you wrote it).

1. PHP ^8.2
2. phpize

This package was built with support for Windows in mind, however, it has not been tested yet.

The below assumes that you’re currently in your application’s root directory.

$ composer require chr1sc0des/phpcrypter --dev

$ ./vendor/bin/phpcrypter generate [--clean] [--] <name> [<payload>]

The below command will generate a unique AES-256-CBC symmetric key named foo:

$ ./vendor/bin/phpcrypter generate foo

Additionally, a .phpcrypter/foo directory will be created in your application’s root, containing a PHP extension skeleton. The symmetric key is the ❤️ of the skeleton 🦴 — they will both be used to later build a binary PHP extension of the same name (foo.so).

A good rule of thumb is one key (and therefore one PHP extension) per project.

The output of the above command will be similar to the following:

Success!
Payload: pAYL0AD==

❗ Please remember to add /.phpcrypter to your .gitignore file.

‼️ Additionally, it is important to save the payload in a password manager, such as 1Password or pass.

$ cd .phpcrypter/foo
$ phpize
$ ./configure
$ make
$ make install

The above commands will build a PHP extension named foo.so and copy it into your PHP extension directory. The directory can be found via the following command:

$ php -i | grep ^extension_dir

You should then add the following line to your php.ini configuration file:

extension=foo.so
foo.decrypt=1

The location of the loaded php.ini configuration file can be found via the following command:

$ php -i | grep "Loaded Configuration File"

Next, verify that the extension is loaded:

$ ./vendor/bin/phpcrypter encrypt <payload> <path>...

The below encrypts multiple directories and files at once. You must specify the previously obtained payload as the first argument.

$ ./vendor/bin/phpcrypter encrypt "pAYL0AD==" \
  "dir-1" \
  "dir-2" \
  "file-1.php" \
  "file-2.php"

❗ The contents of any PHP files found in the above paths will be overwritten. It is highly recommended that you create a new Git branch for these files:

$ git checkout -b encrypted

If you’re just experimenting, it’s useful to be able to encrypt and decrypt at will. The below decrypts any directories and/or files previously encrypted with the payload argument:

$ ./vendor/bin/phpcrypter decrypt <payload> <path>...

❗ Again, the contents of any PHP files found in the above paths will be overwritten.

<?php // @foo
if (! extension_loaded('foo')) exit('The "foo" extension is not loaded');
#pAYL0AD==

The PHP code block should be self explanatory, however, the final line contains a base64 encoded string containing the phpcrypter version, the IV (initialization vector) and the encrypted source code.

By default, when the extension is loaded, it simply hooks into the internals of PHP, namely the zend_compile_file() function, but it doesn’t do anything, unless the foo.decrypt configuration option is set to 1.

In production, it is recommended that you set foo.decrypt to 0 in your php.ini configuration file. This means that there’s no additional overhead for unencrypted PHP files (which will typically be any open source packages in your Composer dependencies).

Then, it is recommended that you use ini_set('foo.decrypt', 1) in any unencrypted PHP files which include/require encrypted files. For example, if you would like to encrypt a controller, you should use ini_set() within an unencrypted base controller. You cannot use ini_set() within encrypted PHP files because zend_compile_file() works at a lower level.

Below are some autocannon benchmarks (10 connections for 10s):

When you’re ready to deploy your encrypted files, you should build an extension for that platform if it differs from your workstation, for example, Linux vs. macOS.

In the event that you need to install multiple extensions on the same server (for different projects), you should consider installing phpcrypter globally:

$ composer global require chr1sc0des/phpcrypter

You must specify the previously obtained payload as the second argument, so that the same key becomes the ❤️ of this skeleton 🦴 too.

$ cd ~/.composer

$ export HISTCONTROL=ignorespace
$  ./vendor/bin/phpcrypter generate foo "pAYL0AD=="
$ unset HISTCONTROL

💡 Using HISTCONTROL=ignorespace prevents any commands that are prefixed with a space from appearing in your shell’s history.

You should refer to the previous section, following the appropriate steps for this particular platform.

You are now ready to deploy your encrypted PHP files! 🚀

The MIT License (MIT).