Before Deployment: What Your Server Looks Like

Step 1: Getting Your Code from GitHub

Step 2: Installing PHP Dependencies

Step 3: Installing and Building Frontend Assets

Step 4: Setting Up the Environment File

Step 5: Running Database Migrations

Step 6: Caching Configuration, Routes, and Views

Step 7: The Symlink Swap (Zero-Downtime Magic)

Step 8: Restarting Workers and Services

Step 9: Your Application Is Live

What Happens When Something Goes Wrong

Deploying Updates

The Big Picture You have been building your Laravel application on your laptop for weeks. Everything works perfectly on localhost. The features are done, the pages look great, and your tests pass. Now you want to put it on the internet so real people can use it. You click "Deploy" in Deploynix, a progress bar fills up, and 60 seconds later your application is live. But what actually happened during those 60 seconds? What did Deploynix do to take your code from a GitHub repository and turn it into a working website? Understanding the deployment process demystifies one of the most intimidating parts of web development. Once you know what is happening under the hood, deployments stop being scary and start being routine. This guide walks through every step of a Laravel deployment in plain language. No jargon, no assumptions about your experience level. If you can build a Laravel app, you can understand how it gets deployed. Before you ever deploy your application, Deploynix has already set up your server with everything Laravel needs to run. Think of your server as a computer in a data center that is always on, always connected to the internet, and always waiting to serve your website. When Deploynix provisions a server, it installs and configures: All of this setup happens once, when you first provision the server. After that, deploying your application is about getting your code onto this server and configuring it to run. The first thing that happens when you click Deploy is that Deploynix copies your application's code from your Git repository (GitHub, GitLab, or Bitbucket) to your server. You have been pushing code to your repository every time you commit changes. Your repository contains everything that makes up your application: the PHP files, the Blade templates, the JavaScript, the configuration files, and the migration files. It is the single source of truth for what your application looks like at any given moment. Deploynix connects to your repository and downloads the latest version of your code to the server. This is similar to what happens when you run git clone on your laptop, except Deploynix is doing it on your server. But here is an important detail: Deploynix does not just dump the code into the same folder every time. It creates a brand new folder for each deployment. If today is your fifth deployment, there are five separate folders on your server, one for each version of your code. We will explain why this matters in a later step. Your Laravel application depends on dozens of packages written by other developers. Things like the Laravel framework itself, the database driver, the authentication system, and any other packages you have added with composer require. These dependencies are listed in your composer.json file but are not stored in your Git repository (the vendor folder is in your .gitignore). After downloading your code, Deploynix runs composer install on the server. This reads your composer.json and composer.lock files, downloads every package your application needs, and puts them in the vendor folder. This step uses the composer.lock file, not just composer.json. The lock file records the exact version of every package that was installed on your development machine. This ensures that the server installs the same versions you tested with, not newer versions that might behave differently. Consistency between your development environment and production is critical. In production, Deploynix passes the --no-dev flag to Composer, which tells it to skip development-only dependencies. Things like Pest (your testing framework) and Laravel Pint (your code formatter) are not needed on a production server, so skipping them makes the installation faster and the application lighter. If your application uses Tailwind CSS, Alpine.js, or any other frontend tools managed through npm, the next step is installing those JavaScript dependencies and compiling your assets. Deploynix runs npm install (or npm ci) to download the JavaScript packages listed in your package.json file. Then it runs npm run build to compile everything into the final CSS and JavaScript files that browsers can understand. During development, you might have been running npm run dev, which watches for file changes and recompiles on the fly. In production, npm run build creates optimized, minified versions of your assets. Minification removes whitespace, shortens variable names, and compresses the files so they are as small as possible. Smaller files mean faster page loads for your users. The compiled files typically end up in your public/build folder. These are the files that Nginx will serve directly to browsers when they request your CSS and JavaScript. Your Laravel application uses a .env file to store configuration that varies between environments. On your laptop, the .env file points to your local database, uses the local app environment, and shows detailed error messages. In production, the configuration is different. Deploynix manages your production environment variables through its dashboard. You set values like your database credentials, your application key, your mail server settings, and any API keys your application needs. Deploynix stores these securely and makes them available to your application through the .env file on the server. Some important differences between your local .env and your production .env: The .env file is never stored in your Git repository (it is in .gitignore). This is intentional. You do not want production database passwords in your code repository. Your application's database starts empty. The structure of your database (the tables, the columns, the indexes) is defined in migration files. Migrations are PHP files in your database/migrations folder that describe each change to your database schema. When Deploynix deploys your application, it runs php artisan migrate to apply any new migrations. This command looks at which migrations have already been run (Laravel tracks this in a special migrations table in your database) and runs only the new ones. For example, if your previous deployment had 15 migrations and you have since added a 16th migration that adds a phone_number column to the users table, the migrate command will only run that 16th migration. The other 15 are already reflected in the database. Migrations are run in order, based on the timestamp in their filename. This ensures that the database structure evolves predictably and consistently, whether you are deploying for the first time or the hundredth time. This step is one of the few parts of deployment that can cause problems if something goes wrong. A migration that fails halfway through can leave your database in an inconsistent state. This is why it is important to test your migrations thoroughly before deploying. Laravel is a feature-rich framework, and loading all of its configuration, routes, and views from scratch on every request takes time. To make your application faster in production, Deploynix runs several caching commands: These caches are rebuilt on every deployment so they always reflect your latest code. Remember how we said that Deploynix creates a new folder for each deployment? Here is why. Your web server (Nginx) is configured to serve your application from a specific path, something like /home/deploynix/yoursite.com/current. But current is not a regular folder. It is a symlink (short for symbolic link), which is essentially a shortcut that points to another folder. Right now, current points to the folder containing your previous deployment's code. All of the steps we have discussed so far (downloading code, installing dependencies, running migrations) happened in a new folder. Your previous version of the application has been running the entire time, serving requests to your users without interruption. Once everything in the new folder is ready, Deploynix updates the current symlink to point to the new folder. This change is atomic, meaning it happens in a single instant. One moment, Nginx is serving the old code. The next moment, it is serving the new code. There is no gap, no moment where the application is unavailable, no half-old-half-new state. This is what "zero-downtime deployment" means. Your users never see an error page or a loading spinner during deployment. They just seamlessly start seeing the new version of your application. The old deployment folders are kept around for a while in case you need to roll back. If something goes wrong with the new deployment, Deploynix can switch the symlink back to the previous folder in seconds, instantly reverting to the last working version. Some parts of your Laravel application run continuously in the background, not just when a user visits a page. Queue workers process jobs that you have queued for background execution. Things like sending emails, processing uploaded images, or generating reports. These workers load your application code into memory when they start and keep running until they are told to stop. After a deployment, the queue workers are still running the old version of your code. Deploynix restarts them so they pick up the new code. This restart is done gracefully: the worker finishes processing its current job, then restarts with the new code. No jobs are lost or interrupted. Cron jobs (scheduled tasks) are managed by Laravel's task scheduler. If you have scheduled commands defined in your application, they continue running on the server's schedule. The next time a scheduled task runs, it automatically uses the new code because it runs fresh through the current symlink. After all of these steps complete, your application is live and serving the latest version of your code. The entire process typically takes between 30 and 90 seconds, depending on the size of your application and the number of dependencies. Here is a summary of what happened: Every subsequent deployment follows the same steps. The process is the same whether it is your second deployment or your two hundredth. Deployments can fail. A migration might have a bug. A Composer dependency might not install correctly. The build step might encounter an error. When this happens, Deploynix stops the deployment before the symlink swap. This is the beauty of the release-folder approach. If something fails during steps 1 through 6, the symlink never changes. Your previous deployment is still running, still serving users, completely unaffected. The failed deployment folder sits there harmlessly, and you can investigate what went wrong without any pressure because your application is still live. If a problem is discovered after the symlink swap (maybe a page throws an error that was not caught during testing), you can use Deploynix's rollback feature. Rolling back switches the symlink back to the previous deployment folder. It takes a few seconds, and your application is back to the last known good version. After your first deployment, every subsequent deployment is the same process. You make changes to your code on your laptop, commit them to Git, push them to GitHub, and deploy through Deploynix. You can deploy manually by clicking the Deploy button in the dashboard, or you can set up automatic deployments that trigger whenever you push to a specific branch. Most teams set up automatic deployments for their main branch. The workflow becomes: write code, open a pull request, get it reviewed, merge it, and the deployment happens automatically. You can also schedule deployments for specific times using Deploynix's scheduled deployment feature, which is useful for changes that should go live during low-traffic hours. Deployment is the bridge between building your application and sharing it with the world. Understanding what happens during deployment makes you a more confident developer. When you know that the symlink swap is what prevents downtime, you can explain it to your team. When you know that migrations run in order, you can write them with confidence. When you know that the .env file is separate from your code, you understand why it is safe to push your code to a public repository. Deploynix automates all of these steps so you can focus on building your application rather than managing servers. But automation works best when you understand what is being automated. Now you do. Go deploy something. Templates let you quickly answer FAQs or store snippets for re-use. as well , this person and/or - The operating system: Ubuntu Linux, which is the most common operating system for web servers.

- PHP: The programming language that Laravel is written in. Deploynix installs the exact version your application needs.- A web server (Nginx): Software that listens for incoming web requests and routes them to your Laravel application. When someone types your domain name into their browser, Nginx is the first piece of software that responds.- A database (MySQL, MariaDB, or PostgreSQL): Where your application stores its data, such as user accounts, posts, orders, and anything else you save to the database.- Composer: The tool that manages your PHP dependencies, which are the packages and libraries your Laravel application uses.- Node.js and npm: Tools for compiling your frontend assets, things like CSS and JavaScript that your browser needs to display your pages. - APP_ENV is set to production instead of local.- APP_DEBUG is set to false so that error details are not shown to users. In development, seeing a full stack trace is helpful. In production, it would expose sensitive information.- APP_URL points to your actual domain name instead of localhost.- Database credentials point to your production database server.- APP_KEY is a unique encryption key that Laravel uses to encrypt cookies, sessions, and other sensitive data. - php artisan config:cache compiles all of your configuration files into a single cached file. Instead of reading dozens of configuration files on every request, Laravel reads one file.- php artisan route:cache compiles your route definitions into a format that Laravel can load faster. If you have dozens or hundreds of routes, this makes a noticeable difference.- php artisan view:cache pre-compiles your Blade templates into plain PHP. Normally, Laravel compiles Blade templates the first time they are requested. Caching them ahead of time means the first visitor to any page gets the same fast response as the thousandth visitor. - Your code was downloaded from GitHub to a new folder on the server.- PHP dependencies were installed with Composer.- Frontend assets were compiled with npm.- The environment configuration was applied.- New database migrations were run.- Configuration, routes, and views were cached.- The symlink was swapped to point to the new code.- Background workers were restarted.