DEV Community: Aboozar Ghaffari

How to Prevent Disasters in Laravel (A Critical Tip for Professional Developers)

Aboozar Ghaffari — Tue, 20 May 2025 17:16:14 +0000

Running powerful Artisan commands like php artisan migrate:fresh or migrate:wipe in the wrong environment—especially production—can completely wipe your database in seconds. To prevent such accidents, Laravel (starting from version 11.9) offers a built-in protection mechanism using the Prohibitable trait. In this tutorial, you’ll learn how to lock down destructive commands in production and avoid unintentional data loss with just a few lines of code.

Prohibitable Trait: Smart Protection Against Destructive Commands

As of Laravel 11.9, you can easily lock dangerous commands in production environments. This simple safeguard can save you from catastrophic errors.

How It Works

By adding a few lines of code to your Service Provider, you can disable certain Artisan commands based on the environment.

class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        FreshCommand::prohibit(app()->isProduction());
        RefreshCommand::prohibit(app()->isProduction());
        ResetCommand::prohibit(app()->isProduction());
        RollbackCommand::prohibit(app()->isProduction());
        WipeCommand::prohibit(app()->isProduction());
    }
}

Here’s why it’s crucial:

migrate:wipe – Completely deletes all database tables (WipeCommand)
migrate:fresh – Resets the entire database (FreshCommand)
migrate:reset – Rolls back all migrations (ResetCommand)
migrate:refresh – Resets and reruns all migrations (RefreshCommand)
migrate:rollback – Reverts the last batch of migrations (RollbackCommand)

The key line is:

WipeCommand::prohibit(app()->isProduction());

This line accepts a boolean. If it returns true, the command is prohibited from running.

The expression app()->isProduction() checks your app’s environment—based on the APP_ENV value in your .env file.

A Simpler Solution

Want to handle all dangerous commands in one place? Just add the second code snippet to your Service Provider, and you’ll be protected across the board.

class AppServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        DB::prohibitDestructiveCommands(app()->isProduction());
    }
}

Final Thoughts

If you’re a professional Laravel developer—or even just getting started—this small tip can save you from a major disaster. Don’t wait for a close call to make this part of your standard setup.

Stay safe. Write smart code.
Laravel has your back—you just need to use the tools it offers.

FrankenPHP: The Modern PHP App Server, written in Go

Aboozar Ghaffari — Thu, 12 Sep 2024 20:31:01 +0000

FrankenPHP is a modern PHP application server built on the Caddy web server, offering developers a powerful alternative to traditional setups like PHP-FPM and Nginx. In this article, I'll explore how FrankenPHP improves performance, simplifies deployment, and enhances security with cutting-edge features like worker mode, real-time event support, and automatic HTTPS. Whether you're working with Laravel, Symfony, WordPress, or other PHP frameworks, discover why FrankenPHP is quickly becoming the go-to solution for developers seeking to optimize their production environments.

If you're a PHP developer looking to improve your application’s performance, security, and deployment process, it's time to consider switching to FrankenPHP as your production web server. Built on the robust Caddy web server, FrankenPHP brings modern innovations that traditional setups like PHP-FPM and Nginx can’t match.

With features like worker mode, which keeps your app in memory for faster performance, and real-time event capabilities that allow seamless communication between your app and the browser, FrankenPHP can significantly boost your app's responsiveness and user experience. It also supports automatic HTTPS, HTTP/2, and HTTP/3, ensuring your app is secure and uses the latest web protocols without any additional configuration.

FrankenPHP also simplifies your deployment by packaging your app as a standalone binary, eliminating the need for managing multiple processes like PHP-FPM and Nginx. Whether you work with Laravel, Symfony, WordPress, or any other PHP framework, FrankenPHP will make your app faster, more efficient, and easier to manage.

For developers looking to streamline their workflow and deliver better performance to end users, switching to FrankenPHP is a smart move. Start exploring today and elevate your PHP projects to the next level.

FrankenPHP at a glance:

Caddy Webserver: Uses the official PHP executor embedded in a state-of-the-art web server: Caddy
Extensible: Compatible with PHP 8.2+, most PHP extensions and all Caddy modules.
Only one service: Designed with simplicity in mind: only one service, only one binary! FrankenPHP doesn’t need PHP-FPM, it uses its own SAPI specially handcrafted for Go web servers.
Easy deploy: Cloud Native app shipped as a Docker image. Compatible with Kubernetes, and all modern cloud platforms. It’s also possible to package your PHP app as a standalone, self-executable static binary.
Worker mode: Boot your application once and keep it in memory! It is ready to handle incoming requests in a few milliseconds.
103 Early Hints: Early Hints are a brand new feature of the web platform that can improve website load times by 30%. FrankenPHP is the only PHP SAPI with Early Hints support!
Real-time: Built-in Mercure hub. Send events from your PHP apps to all connected browsers, they instantly receive the payload as a JavaScript event!
Brotli, Zstandard and Gzip compression: Modern compression formats are supported out-of-the-box.
Structured logging: Bring a more defined format and details to your logging.
Prometheus metrics and tracing: Built-in Prometheus support!
HTTP/2 & HTTP/3: Native support for HTTPS, HTTP/2 and HTTP/3.
HTTPS Automation: Automatic HTTPS certificate generation, renewal and revocation.
Graceful reload: Deploy your apps with zero downtime thanks to graceful reloads.
Supports PHP extension: FrankenPHP supports the most popular PHP extensions, including OPcache and XDebug.

One command to run them all

# Docker
docker run -v $PWD:/app -p 443:443 dunglas/frankenphp

# Static binary
./frankenphp php-server

# Command-line script
./frankenphp php-cli /path/to/your/script.php

Benefits of using FrankenPHP

There are many benefits to using FrankenPHP, including:

Improved performance: FrankenPHP can significantly improve the performance of your PHP app, especially in worker mode. Reduced complexity: FrankenPHP simplifies your deployment process by eliminating the need for separate PHP-FPM and Nginx processes.
Increased security: FrankenPHP automatically supports HTTPS, HTTP/2, and HTTP/3, which helps to keep your app secure.
More features: FrankenPHP offers several features that are not available in traditional PHP application servers, such as early hints and real-time capabilities.

Who should use FrankenPHP?

FrankenPHP is an excellent option for developers looking to enhance the performance, security, and simplicity of deploying their PHP applications. It is particularly well-suited for projects built with Symfony, Laravel, and WordPress.

Getting started with FrankenPHP

Starting with FrankenPHP is simple. Download the FrankenPHP binary from the website and follow the steps provided in the documentation. Additionally, there are numerous tutorials and blog posts available online to guide you through the process.

Conclusion

FrankenPHP is a robust and user-friendly application server designed for PHP. It enhances the performance, and security, and simplifies the deployment process of PHP applications. If you're seeking a cutting-edge solution to streamline your PHP development workflow, FrankenPHP is an excellent choice that offers both efficiency and modern features.

Additional resources
FrankenPHP website: https://frankenphp.dev/
FrankenPHP documentation: https://frankenphp.dev/docs/
FrankenPHP on GitHub: https://github.com/dunglas/frankenphp

Build DOCKER multi-platform image using buildx REMOTE builder NODE

Aboozar Ghaffari — Wed, 02 Aug 2023 21:37:43 +0000

Running applications on different operating systems and processor architectures is a common scenario, so it is a common practice to build separate distributions for different platforms. This is not easy to achieve when the platform we use to develop the application is different from the target platform for deployment. For example, developing an application on an x86 architecture and deploying it to a machine on an ARM platform usually requires preparing the ARM platform infrastructure for development and compilation.

Problem

I recently purchased the new Apple M1 Pro MacBook, which is a high-performance laptop. The M1 Pro (aarch64) processor is very fast and very friendly on the battery, but as I mentioned there are also some - not so small - issues associated with working on a new chip architecture.

I’ve tried to create a few multi-platform docker images with buildx and some are just not correctly emulated on the M1.
The parallelism of buildx was also an issue but the emulation gave me the most trouble.

Solution

Use buildx remote node(s) to build the image on a native architecture.

What do you need?

More than one docker-enabled device in your network or on the internet like:
- Virtual Machine / Server
- Raspberry Pi
- Laptop
- Desktop
ssh access to these devices

In my case I have a CX11 VM on HETZNER that is **amd64/x86_64** based and my own M1 Pro that is **arm64/aarch64** based. Since Hetzner now offers arm64 machines, you can also do it the other way around too.

How I did do this?

Step 1: Installation

Since the newer versions of Docker, Buildx (Buildkit) is a built-in function, to check its availability, use the following command.



❯ docker buildx version
github.com/docker/buildx v0.11.1 b4df08551fb12eb2ed17d3d9c3977ca0a903415a

Step 2: Setup ssh access for your remote node

The remote host where we also want to run Docker needs to be configured with a password-less SSH connection. This post will not explain how to do that as there are many articles explaining how to set up public/private key access to a device.

If you already have the keys you can copy them to your target device like so:



ssh-copy-id USERNAME@TARGET_VM_HOST

To run a command with the user environment available you need to make sure your sshd service allows it.
When running a command through ssh you will have a limited environment and that needs to be adjusted.

To have a correct environment where docker is known you need to set the #PermitUserEnvironment no property to PermitUserEnvironment yes in the /etc/ssh/sshd_conf file on your VM.
When this is adjusted you need to restart the sshd service. On my CX11 VM with the Ubuntu server, I used this command. It might be different for your device:



sudo systemctl restart sshd

Now you have to set the environment for ssh:

login to your VM through the terminal (ssh USER_HERE@TARGET_VM_HOST)
cd ~/.ssh create a file called environment with the following value in it



PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

the last /usr/local/bin is where the docker command lives. So now it will be available.

Check if you can run docker with the command below from local machine/laptop. It should work:



docker -H ssh://USERNAME_HERE@TARGET_VM_HOST info

Do not forget to change the command's values to appropriate ones for your situation.

Step 3: Create a buildx local node

Let’s first create the local platform. In my case that is the Apple M1 Pro node. It should build all the arm64/aarch64 targets.



docker buildx create \
  --name local_remote_builder \
  --node local_remote_builder \
  --platform linux/arm64,linux/riscv64,linux/ppc64le,linux/s390x,linux/mips64le,linux/mips64,linux/arm/v8,linux/arm/v7,linux/arm/v6 \
  --driver-opt env.BUILDKIT_STEP_LOG_MAX_SIZE=10000000 \
  --driver-opt env.BUILDKIT_STEP_LOG_MAX_SPEED=10000000

I’ve played a bit with the settings but this seems to work best for me. I will update as needed or if I find settings that work even better.

Now we have a local config for a builder called local_remote_builder.

You can check if you have it by running docker buildx ls command:



NAME/NODE   DRIVER/ENDPOINT     STATUS PLATFORMS
local_remote_builder * docker-container
    local_remote_builder unix:///var/run/docker.sock running linux/arm64*, linux/riscv64*, linux/ppc64le*, linux/s390x*, linux/mips64le*, linux/mips64*, linux/arm/v7*, linux/arm/v6*, linux/amd64, linux/amd64/v2, linux/386

Step 4: Create a target buildx remote node

In my case, this will be the amd64/x86_64 builder node. The platforms corresponding to that architecture should be sent there.
We have already configured the SSH access and the environment and tested that docker can access it.

Now we need to add it to the buildx target



docker buildx create \
    --name local_remote_builder \
    --append \
    --node intelarch \
    --platform linux/amd64,linux/386 \
    ssh://USERNAME@TARGET_VM_HOST \
    --driver-opt env.BUILDKIT_STEP_LOG_MAX_SIZE=10000000 \
    --driver-opt env.BUILDKIT_STEP_LOG_MAX_SPEED=10000000

Do not forget to change the command's values to appropriate ones for your situation.

This command will append the remote node to the local_remote_builder and call the node intelarch. You can check it again by running docker buildx ls command again:



NAME/NODE              DRIVER/ENDPOINT        STATUS  BUILDKIT             PLATFORMS
local_remote_builder * docker-container                                    
  local_remote_builder orbstack               running v0.11.6              linux/arm64*, linux/riscv64*, linux/ppc64le*, linux/s390x*, linux/mips64le*, linux/mips64*, linux/arm/v7*, linux/arm/v6*, linux/amd64, linux/amd64/v2, linux/386
  intelarch            ssh://aboozar@167.21.183.24 running v0.11.6              linux/amd64*, linux/386*, linux/amd64/v2, linux/amd64/v3

Step 5: buildx use and bootstrap

In order to start using this builder setup we need to tell buildx to start using it and we need to bootstrap it.



docker buildx use local_remote_builder
docker buildx inspect --bootstrap

output:



#1 [intelarch internal] booting buildkit
#1 starting container buildx_buildkit_intelarch
#1 ...

#2 [localremote_builder internal] booting buildkit
#2 pulling image moby/buildkit:buildx-stable-1 1.6s done
#2 creating container buildx_buildkit_local_remote_builder 0.6s done
#2 DONE 2.3s

#1 [intelarch internal] booting buildkit
#1 starting container buildx_buildkit_intelarch 3.6s done
#1 DONE 3.6s
Name:   localremote_builder
Driver: docker-container

Nodes:
Name:      local_remote_builder
Endpoint:  unix:///var/run/docker.sock
Status:    running
Platforms: linux/arm64*, linux/riscv64*, linux/ppc64le*, linux/s390x*, linux/mips64le*, linux/mips64*, linux/arm/v7*, linux/arm/v6*, linux/amd64, linux/amd64/v2, linux/386

Name:      intelarch
Endpoint:  ssh://aboozar@167.21.183.24
Status:    running
Platforms: linux/amd64*, linux/386*, linux/amd64/v2

Step 6: Build a multi-platform image

The command below will build for amd64 and arm64 but will direct the amd64 build to the remote node and the arm64 build will be done on the local machine.



docker buildx build --platform=linux/amd64,linux/arm64/v8 --push -t name/target:tag .

This will result in something like this on the docker hub:

Conclusion

The most obvious issue in this setup is that I can only build for multiple platforms when within my own network.
That is not necessarily true if you used a remote ssh accessible host or IP. I did not do that and that limits me to these builds when I have my remote node available in the network. For now, that is not a real issue for me.

It solved my concurrency problem. I had one build where I had to start the server, in order to configure it, during the docker build. Buildx does this in parallel and that gave me a port conflict as one was a bit faster but not ready when the other also tried to start. That was a problem when I tried to build all on only my local node. When I added the remote node this problem went away as the port was used on a completely different machine.

Overall, I am currently content with this solution.