Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/OswalSnow/AR-Barber/llms.txt

Use this file to discover all available pages before exploring further.

Deploying AR Barbería to production requires a few additional steps beyond the local development setup. You need to harden the environment configuration, compile frontend assets, apply migrations with the --force flag, link the storage directory for portfolio image access, cache the framework configuration, and ensure your web server can write to the correct directories. This page walks through each step in order.

​
Pre-deployment checklist

Before uploading any files or running commands on the server, verify the following settings in your production .env file:
1

Disable debug mode and set production environment

APP_ENV=production
APP_DEBUG=false
Deploying with APP_DEBUG=true exposes stack traces, environment variable values, and internal file paths to end users. This is a critical security risk — always set it to false in production.
2

Generate the application key

If this is a fresh environment, generate the encryption key:
php artisan key:generate
If you are migrating from another server, copy the existing APP_KEY value — changing it invalidates all active sessions.
3

Configure a production database

Switch from SQLite to MySQL or PostgreSQL. SQLite is file-based and not suitable for concurrent production traffic.
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=arbarberia
DB_USERNAME=arbarberia_user
DB_PASSWORD=your_secure_password
4

Set the application URL

APP_URL=https://yourdomain.com
AR Barbería uses APP_URL to generate absolute URLs for portfolio images and email links. Set it to the exact domain users will access, including the protocol.

​
Build production assets

Compile and minify the frontend JavaScript and CSS with Vite: 
npm ci
npm run build
Use npm ci instead of npm install on production servers. It installs exact versions from package-lock.json and fails if the lockfile is out of sync, making builds reproducible.

​
Run database migrations

Apply all pending migrations. The --force flag is required in production environments because Laravel otherwise refuses to run migrations when APP_ENV=production as a safety measure: 
php artisan migrate --force
AR Barbería stores portfolio images in storage/app/public. Create a symlink so the web server can serve them from the public/ directory: 
php artisan storage:link
Run this command once per environment after the first deployment. Re-run it if the public/storage symlink is ever deleted.

​
Optimize for production

Cache the framework’s configuration, route list, and compiled Blade views to eliminate filesystem reads on every request: 
php artisan config:cache
php artisan route:cache
php artisan view:cache
Run these three commands as part of your deployment pipeline after every code change. If you change .env values, clear and rebuild the config cache with php artisan config:clear && php artisan config:cache.

​
File permissions

The web server process (typically www-data on Nginx/Apache) must be able to write to two directories: 
chmod -R 775 storage
chmod -R 775 bootstrap/cache
chown -R www-data:www-data storage bootstrap/cache
DirectoryPurpose
storage/Logs, cached views, compiled files, uploaded portfolio images.
bootstrap/cache/Cached configuration, routes, and services.
Do not set these directories to 777. World-writable permissions allow any process on the server to modify application files.

​
Docker-based deployment with Laravel Sail

AR Barbería ships with Laravel Sail for Docker-based deployments. To start the full application stack in detached mode: 
./vendor/bin/sail up -d
Sail starts PHP-FPM, the database server, and any configured services (Redis, Mailpit, etc.) defined in docker-compose.yml. After the containers are running, execute the post-deploy commands inside the container: 
./vendor/bin/sail artisan migrate --force
./vendor/bin/sail artisan storage:link
./vendor/bin/sail artisan config:cache
./vendor/bin/sail artisan route:cache
./vendor/bin/sail artisan view:cache

​
Queue worker

The development script uses php artisan queue:listen, which is convenient locally but unsuitable for production because it does not restart automatically after failures. In production, manage the queue worker with a process supervisor such as Supervisor:
supervisor.conf
[program:arbarberia-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/html/artisan queue:work --tries=3 --timeout=90
autostart=true
autorestart=true
user=www-data
numprocs=2
redirect_stderr=true
stdout_logfile=/var/www/html/storage/logs/worker.log
stopwaitsecs=3600
After deploying new code, restart the queue workers so they load the updated application:
php artisan queue:restart
Running workers continue processing the current job before stopping. Supervisor restarts them automatically.

​
Booking endpoint rate limiting

The appointment booking endpoint is protected by Laravel’s throttle:3,1 middleware, which limits each IP address to 3 requests per minute. This is enforced at the routing level and requires no additional configuration. If you place AR Barbería behind a reverse proxy (Nginx, Cloudflare, etc.), ensure the proxy forwards the real client IP using the X-Forwarded-For header and that Laravel’s TrustProxies middleware is configured to trust your proxy’s IP range. Without this, all requests appear to come from the proxy’s IP and the rate limiter will not work correctly.

Build docs developers (and LLMs) love

Get started for freeTalk to us