You know, when you go to a pizza place, they give you a little number on a stand so the waiter knows which table ordered what? That number doesn’t store your pizza — it just tells the kitchen, “Hey, Table 7 wants a large pepperoni.”

That’s kind of how sessions work in PHP.

When you visit a website, PHP gives you a unique session ID (like your table number). This ID helps the server remember stuff about you — like your login status, shopping cart, or form inputs — without mixing you up with someone else.

The actual data (your “pizza”) gets stored on the server, and PHP uses the session ID to match it with you every time you visit a new page. That way, the site doesn’t forget who you are after every click.

So, How Does It Work in PHP?

Okay, so that’s the pizza place version — but how does this actually work in PHP? Let’s break it down with a real example.

To start a session, use this line at the very top of your PHP file (before any output):

<?php
session_start();
?>

This tells PHP:

• “Hey, check if this user already has a session,” or
• “If not, create a new one.”

Once that’s done, you can store data like this:

$_SESSION['username'] = 'muhalvin';
$_SESSION['logged_in'] = true;

And later, on another page:

echo $_SESSION['username']; // outputs 'muhalvin'

That data is stored on the server, and the user’s browser holds a session ID (usually in a cookie called PHPSESSID) so PHP can match the request with the right session data.

Common Mistakes I Made (and How to Avoid Them)

When I first used sessions, I ran into a few problems — here are the big ones:

I forgot session_start();

Without this, $_SESSION just won’t work. It always needs to be the first thing in your script — before any output, even a blank space.

I had output before the session started

If you echo something or accidentally leave a space before <?php, you’ll get a “headers already sent” error. Sessions modify headers, so they must be started before anything gets sent to the browser.

I thought sessions were automatically secure

Sessions help store data, but they’re not a security system on their own. Always use HTTPS, validate user input, and regenerate session IDs on login with:

session_regenerate_id(true);

This helps prevent session hijacking.

Logging Out (Destroying the Session)

To end a session — like logging a user out — you can use:

session_start();
session_unset();     // Clear session variables
session_destroy();   // End the session completely

This deletes the data and removes the session ID, so the user is no longer recognized.

Hope this explanation made sessions feel a little less scary! If you’ve got questions or want me to break down another PHP concept, let me know — I’m still learning too.

And if your session data suddenly disappears, don’t worry — it’s probably not PHP being mean. It’s just you forgetting session_start(); (again). Happens to the best of us.

“If sessions were a friend, they’d be that one guy who wants to remember your name, but only if you start the conversation properly.”

Explaining Sessions in PHP Like I’m 5 was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

As a web developer, I am always looking for ways to write clean, well-structured, and scalable code. One topic that often comes up in web application development is how to store session data. Sessions are a crucial element in web applications, especially in authentication systems and session management. The decision on how to store sessions can significantly impact the performance, security, and scalability of the applications we build.

In this article, I will discuss two main approaches to session storage in web applications: file-based sessions and database-based sessions. We will explore their advantages, disadvantages, and use cases based on my experience as a PHP developer. Hopefully, after reading this article, you can make a more informed decision when choosing the right session driver for your project.

Introduction: The Importance of Session Storage in Web Applications

Before diving deeper into the comparison between file sessions and database sessions, let’s first understand why sessions are important. In web applications, sessions are used to store temporary data related to active users. Typically, sessions store authentication information, user preferences, or other states that need to persist during a session.

For example, when a user logs into an application, we want to store data such as the user ID or login status in the session. This way, the user doesn’t have to log in again every time they load a new page. However, to make this session system work effectively, we need to carefully consider how and where this session data will be stored. This decision affects application performance, security, and ease of session data management.

Technical Explanation: File Session vs. Database Session

File Session

File-based sessions are the traditional approach where session data is stored in files on the server. Typically, these files are stored in a specific directory accessible by the server. For instance, in PHP, session files are stored in /tmp or a directory configured in the php.ini file.

Each session is usually stored in a separate file with a unique name (e.g., based on the session ID). When a user accesses the application, the server reads the corresponding session file to retrieve the stored data.

How File Sessions Work:

1. The PHP server generates a file with a unique ID for each session.
2. Session data is stored in this file.
3. When an HTTP request comes in, the session ID is sent via a cookie or URL parameter.
4. The server opens the session file based on the ID and loads the stored data.

Database Session

In contrast, database sessions store session data in a database table rather than in files. This is a more modern approach and is often used in applications requiring greater scalability. Session data is stored as rows in a database table, with columns recording information such as the session ID, user ID, last activity time, and other session data.

How Database Sessions Work:

1. The PHP server generates a session ID, similar to file sessions.
2. Session data is stored in a database table.
3. When a request comes in, the session ID is used to look up the corresponding data in the database.
4. Database sessions can include validation mechanisms such as expiration time or last activity time.

Comparison / Evaluation

Now, let’s dive into the technical aspects: how these two approaches compare in several key areas.

1. Performance

File Sessions: File sessions tend to be faster in small applications or on servers with only a few users. Since the data is stored in local files, there is no additional overhead from database queries. This makes session data access very fast.

However, issues arise as the application grows. If the number of users increases, the number of files to manage also grows, which can slow down the server-especially on shared hosting or servers handling many concurrent requests.

Database Sessions: On the other hand, database sessions offer more stable performance in large applications with many users. Databases are designed to handle numerous queries and can be optimized for indexing, caching, and complex queries.

However, there is additional overhead because every time session data needs to be accessed, the server must query the database. For applications with extremely high request volumes, this can be slightly slower than file sessions.

2. Security

File Sessions: One challenge with file sessions is managing these files securely. If session files are not properly protected, there is a risk of unauthorized access. This is especially true for applications hosted on shared servers, where access to session files can become a security concern.

Database Sessions: Database sessions are generally more secure because session data is stored in a database with stricter access controls. Additionally, session data can be encrypted in the database for an extra layer of security.

However, it’s important to note that storing sessions in a database is not entirely risk-free. The database must also be well-secured, and session encryption is crucial for protecting sensitive data.

3. Scalability

File Sessions: File sessions have limited scalability, especially in large applications or those running on multiple servers. If an application runs on several servers, each server needs equal access to the session files. One solution is to use a distributed storage system like NFS (Network File System), but this can get complicated.

Database Sessions: Database sessions excel in scalability, particularly when an application spans multiple servers. By storing sessions in a database, we can easily share sessions across servers without worrying about file synchronization.

4. Maintenance

File Sessions: Maintaining file sessions is relatively simple since it only involves managing files. However, if there are a large number of session files, cleaning up expired sessions can become challenging. PHP has a garbage collector to help, but sometimes additional configuration is needed.

Database Sessions: Maintaining database sessions is more complex because it requires managing tables and queries. However, this approach offers greater flexibility in session data management, such as adding columns for extra information, querying active sessions, and more.

Case Study from Personal Experience

When developing the authentication system, I initially used file sessions. This worked well during development and for applications with a limited number of users. However, as the application grew, I encountered performance issues when the number of users increased and the server had to handle more requests.

Eventually, I switched to database sessions. I created a sessions table in the database and stored session data there. This greatly helped in managing sessions across servers and provided more flexibility in session data management. Additionally, I could implement validation mechanisms such as expiration time and last activity time, which were very useful for keeping sessions secure.

Conclusion and Best Practices

So, when should you use file sessions, and when should you use database sessions? Here are some tips based on my experience:

• Use file sessions if your application is small and doesn’t require server distribution or if you’re not overly concerned about long-term scalability. File sessions are suitable for applications with a limited number of users that don’t require highly secure or distributed session storage.
• Use database sessions if your application requires greater scalability and flexibility. Database sessions are more secure, easier to maintain, and more efficient for larger applications or those hosted on multiple servers.

Some implementation tips:

• Always encrypt sensitive session data.
• Consider using sessions with expiration times to reduce database or file system load.
• Ensure garbage collection works properly, whether for file sessions or database sessions.

I hope this article provides valuable insights and helps you make the right decision for your application’s session system!

This guide will walk you through the complete installation of Virtualmin on an Ubuntu 24.04 VPS. No advanced technical knowledge is required — just follow each step carefully.

Step 1: Prepare the Server

Before starting the installation, make sure your server meets the following requirements:

• A fresh installation of Ubuntu 24.04 without additional software.
• Root access or a user with sudo privileges.
• At least 1GB of RAM (2GB or more is recommended for better performance).
• A fully qualified domain name (FQDN), such as server.example.com.

Setting the Hostname

Virtualmin requires a properly configured hostname for smooth operation. To set it, run the following command:

sudo hostnamectl set-hostname server.yourdomain.com

Replace server.yourdomain.com with your actual domain or subdomain.

Step 2: Update the System

To ensure system stability, update all existing packages before proceeding with the installation. Run:

sudo apt update && sudo apt upgrade -y

This step may take a few minutes depending on the server’s performance and internet speed.

Step 3: Install Virtualmin

The easiest way to install Virtualmin is by using the official install script.

Download and Run the Installer

Run the following command:

sudo sh -c "$(curl -fsSL https://software.virtualmin.com/gpl/scripts/virtualmin-install.sh)" -- --bundle LAMP

This script will:

• Install Webmin & Virtualmin
• Set up Apache, MySQL/MariaDB, PHP, and Postfix
• Optimize your server for web hosting

Alternative Installation (Using Nginx Instead of Apache)

If you prefer Nginx instead of Apache, use this command instead:

sudo sh -c "$(curl -fsSL https://software.virtualmin.com/gpl/scripts/virtualmin-install.sh)" -- --bundle LEMP

Wait for the Installation to Complete

The installation process usually takes between 10 to 20 minutes. If prompted, confirm the process by typing Y and pressing Enter.

Step 4: Access Virtualmin Web Interface

Once installed, you can access Virtualmin through your web browser.

Open Virtualmin in Your Browser

https://YOUR-SERVER-IP:10000

(Replace YOUR-SERVER-IP with your actual server's IP address.)

Login Details

• Username: root
• Password: (Your root password for the server)

SSL Warning: Your browser might show a security warning because Virtualmin uses a self-signed SSL certificate. Click “Advanced” and then “Proceed” to continue.

Step 5: Complete Virtualmin Setup

After logging in, you’ll see the Post-Installation Wizard. Follow these steps:

Memory Usage Optimization

• If your VPS has less than 2GB RAM, enable memory optimizations.
• Otherwise, select “No” and continue.

Database Selection

• Keep MySQL/MariaDB as the default option.

DNS and Email Configuration

• If you plan to use email hosting, enable it.
• Otherwise, disable mail processing to save server resources.

4️⃣ Click “Re-Check and Refresh Configuration”

• This will verify that your server is correctly set up.

Step 6: Create Your First Website (Optional)

If you want to host a website, follow these steps:

1. In Virtualmin, go to “Create Virtual Server”.
2. Enter your domain name (e.g., example.com).
3. Set an Admin Password for the website.
4. Click “Create Server” — your website is now ready! 🎉

Step 7: Secure Virtualmin (Recommended)

To enhance security, follow these steps:

Change the Default Webmin Port (10000)

• Go to Webmin > Webmin Configuration > Ports and Addresses
• Change 10000 to a custom port (e.g., 2345)

Enable a Firewall

• Go to Networking > Linux Firewall
• Allow only necessary ports (22, 80, 443, and your custom Webmin port)

Enable SSL with Let’s Encrypt

• Go to Server Configuration > Manage SSL Certificate
• Request a free SSL certificate for your domain

Conclusion

Virtualmin simplifies server management by providing a web-based control panel for website hosting, database management, and email services. By following this guide, you have successfully installed and configured Virtualmin on Ubuntu 24.04.

Now, you can:

• Host and manage multiple websites.
• Set up and configure databases easily.
• Manage email accounts and DNS settings.

For additional configuration and optimization, explore the Virtualmin documentation or community forums.

How to Install Virtualmin on Ubuntu 24.04 VPS (Beginner-Friendly Guide) was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In modern software development, Continuous Integration and Continuous Deployment (CI/CD) are essential practices to ensure that code changes are automatically tested, built, and deployed to production environments. In this article, we’ll explore how to set up a simple GitLab CI/CD pipeline using Deployer, a deployment tool for PHP applications, to automate the deployment of a Laravel application.

While this setup provides a straightforward and effective way to deploy your application, it’s important to note that additional optimizations are required for enhanced security in production environments. Let’s dive in!

Why Use Deployer with GitLab CI/CD?

Deployer is a popular PHP deployment tool that simplifies the process of deploying applications to remote servers. It supports various frameworks, including Laravel, and provides a clean and easy-to-use interface for managing deployments. By integrating Deployer with GitLab CI/CD, we can automate the entire deployment process, ensuring that our application is always up-to-date and running smoothly.

This guide focuses on a simple setup to get you started quickly. However, for production-grade security, you should consider additional optimizations, such as stricter SSH configurations, secret management, and access controls.

Prerequisites

Before we dive into the setup, ensure you have the following:

1. A Laravel application hosted on GitLab.
2. A production server (e.g., a VPS) with SSH access.
3. GitLab CI/CD enabled for your repository.
4. SSH keys configured for secure communication between GitLab and your production server.

Step 1: Installing deployer

Deployer will prompt you with a series of questions. After completing them, you’ll have a deploy.php or deploy.yaml file — your deployment recipe. This file defines hosts, tasks, and dependencies on other recipes. Framework-specific recipes provided by Deployer are based on the common recipe.

For recipe language, type 0 for PHP:

Choose recipe language (0 for PHP, 1 for YAML) [0]:

And for project template, type 12 for Laravel:

Choose your project type [0]:
...
12 - Laravel

This will generate a deploy.php file tailored for Laravel applications.

Step 2: Setting Up Deployer

First, we need to configure Deployer for our Laravel application in the root of your project with the following configuration:

<?php

namespace Deployer;

require 'recipe/laravel.php';
require 'recipe/deploy/writable.php';

// General configuration
set('application', 'Laravel');
set('repository', 'git@gitlab.com:username/repo.git'); // Replace with your Git repository URL
set('keep_releases', 3);

// Shared files and directories
add('shared_files', ['.env']);
add('shared_dirs', ['storage']);
add('writable_dirs', [
    "bootstrap/cache",
    "storage",
    "storage/app",
    "storage/framework",
    "storage/logs",
]);

// Use chmod as an alternative to ACL
set('writable_mode', 'chmod');

// Composer options
set('composer_options', '--verbose --prefer-dist --no-progress --no-interaction --no-dev --optimize-autoloader');

// Host for production (main branch)
host('192.168.1.1') // Replace with your production server IP
    ->set('remote_user', 'root')
    ->set('branch', 'main') // Only deploy from the main branch
    ->set('deploy_path', '/home/username/public_html'); // Replace with your production deployment path

// Hooks
task('deploy:secrets', function () {
    // Copy .env.example to .env if .env does not exist
    if (!file_exists(__DIR__ . '/.env')) {
        copy(__DIR__ . '/.env.example', __DIR__ . '/.env');
    }

    upload('.env', get('deploy_path') . '/shared');
})->desc('Upload .env file');


// Define npm:install task
task('npm:install', function () {
    run('cd {{release_path}} && npm install');
})->desc('Install npm dependencies');

// Define npm:build task
task('npm:build', function () {
    run('cd {{release_path}} && npm run build');
})->desc('Run npm build');

task('deploy:build', [
    'npm:install',
    'npm:build',
])->desc('Build assets');

task('deploy', [
    'deploy:prepare',
    'deploy:secrets',
    'deploy:vendors',
    'deploy:shared',
    'artisan:storage:link',
    'artisan:view:cache',
    'artisan:config:cache',
    'artisan:route:cache',
    'artisan:migrate',
    'artisan:queue:restart',
    'deploy:build',
    'deploy:publish',
    'deploy:unlock',
])->desc('Deploy your project');

// [Optional] Automatically unlock if deployment fails
after('deploy:failed', 'deploy:unlock');

// Rollback task
task('rollback', function () {
    $releases = get('releases_list');
    if (isset($releases[1])) {
        $releaseDir = "{{deploy_path}}/releases/{$releases[1]}";
        run("ln -nfs $releaseDir {{deploy_path}}/current");
        run("rm -rf {{deploy_path}}/releases/{$releases[0]}");
        writeln("Rollback to `{$releases[1]}` release was successful.");
    } else {
        writeln("No more releases to rollback to.");
    }
})->desc('Rollback to previous release');

Key Points in deploy.php:

1. Shared Files and Directories: The .env file and storage directory are shared across releases to maintain configuration and data consistency.
2. Production Host Configuration: Replace 123.456.789.0 and /home/username/public_html with your server’s IP and deployment path.
3. Environment Secrets: The deploy:secrets task handles the .env file securely by uploading it to the shared directory.

Step 3: Configuring GitLab CI/CD

Next, we’ll set up the GitLab CI/CD pipeline to automate the build and deployment process. Create a .gitlab-ci.yml file in the root of your project:

stages:
  - build
  - deploy

# Cache node_modules to speed up builds
cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/

# Build stage to compile assets (JavaScript/CSS)
build_assets:
  stage: build
  image: node:latest
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - public/  # Save build results in the public folder
    expire_in: 3 days  # Delete artifacts after 3 days
  only:
    - main  # Only run for the main branch

# Deploy stage to production
deploy_production:
  stage: deploy
  image: php:8.3-cli
  before_script:
    - apt-get update && apt-get install -y git unzip openssh-client rsync
    - curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
    - composer global require deployer/deployer --no-progress --no-interaction
    - mkdir -p ~/.ssh
    - echo "$SSH_PRIVATE_KEY" | tr -d '\r' > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
    - echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
    - chmod 644 ~/.ssh/known_hosts
  script:
    - export PATH="$PATH:$HOME/.composer/vendor/bin"
    - dep deploy --branch=main
  only:
    - main
  environment:
    name: production
    url: https://yourproduction.url  # Replace with your production URL
  cache: {}  # Disable cache for the deploy stage

Key Points in .gitlab-ci.yml:

1. Build Stage: The build_assets job compiles JavaScript and CSS assets using Node.js. The artifacts are stored in the public folder and expire after one week.
2. Deploy Stage: The deploy_production job installs dependencies, sets up SSH keys, and runs the dep deploy command to deploy the application to the production server.
3. Environment Variables: Ensure you set the SSH_PRIVATE_KEY and SSH_KNOWN_HOSTS variables in GitLab’s CI/CD settings for secure SSH communication.

How to Add SSH_PRIVATE_KEY to GitLab CI/CD

To allow GitLab to connect to the server via SSH for deployment using Deployer, you need to add the private key (SSH_PRIVATE_KEY) to GitLab CI/CD. Follow these steps:

1. Generate an SSH Key Locally

If you don’t already have an SSH key, generate a new one on your local machine or deployment server:

ssh-keygen -t rsa -b 4096 -C "gitlab-deployer"

• -t rsa: Uses the RSA algorithm.
• -b 4096: Generates a 4096-bit key for higher security.
• -C "gitlab-deployer": Adds a comment for identification.

When prompted for the file location, press Enter to use the default (~/.ssh/id_rsa). If you prefer a different name, specify it when prompted.

2. Copy the Private Key

After generating the key, display the private key:

cat ~/.ssh/id_rsa

Copy the output (starting with -----BEGIN OPENSSH PRIVATE KEY----- and ending with -----END OPENSSH PRIVATE KEY-----).

3. Add the Private Key to GitLab CI/CD

1. Open your GitLab repository.
2. Navigate to Settings → CI/CD.
3. Expand the Variables section.
4. Click Add variable and fill in the details:

• Key: SSH_PRIVATE_KEY
• Value: Paste the copied private key.
• Type: Variable
• Masked: Enable (to hide it from logs)
• Protected: Enable (so it can only be accessed in protected branches, like main)

4. Add the Public Key to the Server

Copy the public key so the server recognizes GitLab as a trusted source:

cat ~/.ssh/id_rsa.pub

Copy the output and add it to the ~/.ssh/authorized_keys file on your target server

echo "your_public_key_here" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

5. Test SSH Connection from GitLab Runner

To verify that GitLab can connect to the server, run the following command from the GitLab CI/CD Runner:

ssh -i ~/.ssh/id_rsa -o StrictHostKeyChecking=no user@your.server.ip

If you can log in without entering a password, the SSH configuration is correct.

How to Get SSH_KNOWN_HOSTS

To securely connect to your server, you need to add the server’s SSH fingerprint to the SSH_KNOWN_HOSTS variable. Here's how to get it:

Run the following command on your local machine or CI/CD environment:

ssh-keyscan -t rsa your.server.ip

Copy the output and add it as the value of the SSH_KNOWN_HOSTS variable in GitLab’s CI/CD settings.

Step 4: Securing Your Deployment

This setup provides a simple and effective way to deploy your application. However, additional optimizations are required for enhanced security in production environments. Here are some recommendations:

1. SSH Key Management:

• Use a dedicated deployment user with limited permissions instead of the root user.
• Restrict SSH access to specific IP addresses using firewall rules (e.g., ufw).
• Use SSH certificates or multi-factor authentication (MFA) for added security.

2. Environment Variables:

• Avoid hardcoding sensitive data in your .env file. Use GitLab’s CI/CD variables or a secrets management tool like HashiCorp Vault.
• Encrypt sensitive data before storing it in version control.

3. Deployer Configuration:

• Use writable_mode with acl if your server supports it, as it provides better permission handling than chmod.
• Implement rollback mechanisms in case of deployment failures.

4. CI/CD Pipeline Security:

• Restrict access to the GitLab CI/CD settings to authorized personel only.
• Regularly review and update your pipeline configuration to address new security vulnerabilities.

Step 5: Running the Pipeline

Once everything is set up, push your changes to the main branch. GitLab will automatically trigger the CI/CD pipeline:

1. The build_assets job will compile your assets.
2. The deploy_production job will deploy your application to the production server.

You can monitor the pipeline’s progress in GitLab’s CI/CD section.

Conclusion

By combining GitLab CI/CD with Deployer, we’ve created a simple and effective deployment pipeline for our Laravel application. This setup ensures that every change pushed to the main branch is automatically tested, built, and deployed to production, saving time and reducing the risk of human error.

However, it’s important to remember that this is a basic setup. For production environments, additional security optimizations are necessary to protect your application and infrastructure. Always follow best practices for SSH key management, secret handling, and access control.

Feel free to customize the deployer.php and .gitlab-ci.yml files to suit your specific needs. If you found this article helpful, don’t forget to share it with your team and follow me on Medium for more tutorials.

Automating Deployment with GitLab CI/CD and Deployer for Laravel Applications: A Simple Approach was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In web design, choosing the right background color is crucial for user comfort. While pure white (#FFFFFF) is often used for its clean and minimalist appearance, it can be too bright and cause eye strain, especially during prolonged screen exposure. To address this issue, softer white alternatives — often called off-white or soft white — can be a better choice.

Why Not Use Pure White?

Pure white has the highest brightness level, which can create excessive contrast when paired with black or dark-colored text. This strong contrast may lead to discomfort and fatigue, particularly when reading long-form content or browsing a website for an extended period.

Instead, off-white shades provide a gentler, more visually pleasant alternative while maintaining a clean and professional look.

Best Off-White Colors for Web Design

Here are some soft white colors that are more comfortable for the eyes compared to pure white:

• Snow (#FAFAFA) — A very soft white that is almost indistinguishable from pure white but appears less harsh. It provides a clean and minimalist look while being easier on the eyes.
• Ivory (#FFFFF0) — A slightly warm white with a hint of yellow, giving it a natural and cozy feel. This color works well in designs that aim for warmth and elegance.
• Seashell (#FFF5EE) — A soft white with subtle pink undertones, making it look warm and inviting. This shade is great for websites that want to create a welcoming atmosphere.
• Ghost White (#F8F8FF) — A white with a cool blue tint that gives an airy and refreshing feel. It’s an excellent choice for modern, professional, or technology-focused designs.
• Alabaster (#F2F2F2) — A very light grayish-white that appears softer than pure white. This shade is ideal for reducing contrast and improving readability, especially on text-heavy websites.

Recommended Background Colors for Websites

When designing a website, the goal is to find a background color that reduces eye strain while keeping a modern and clean aesthetic. The following two shades work exceptionally well for web backgrounds:

1. #FAFAFA (Snow) — This color is very close to pure white but appears softer and less glaring. It’s ideal for minimalist designs that still want a crisp look without excessive brightness.
2. #F2F2F2 (Alabaster) — This is a very light gray that resembles white but is much gentler on the eyes. It helps reduce contrast while maintaining readability, making it perfect for text-heavy websites.

Both of these colors offer a balance between readability and comfort, making them excellent choices for blog backgrounds, content-heavy pages, and user interfaces that require prolonged engagement.

How to Apply Off-White Colors in Web Design

1. Using CSS to Set Background Colors

To apply an off-white background color in your website, you can modify your CSS styles like this:

body {
    background-color: #FAFAFA; /* Soft white background */
    color: #333; /* Dark gray text for better readability */
    font-family: Arial, sans-serif;
}

If you prefer a slightly darker but still soft background, use:

body {
    background-color: #F2F2F2; /* Alabaster background */
    color: #222; /* Slightly darker text for contrast */
}

2. Combining with Other Colors

Off-white shades work well with a variety of accent colors. Here are some pairing recommendations:

• For a modern look: Combine #FAFAFA with black or dark gray text and blue accent colors.
• For a warm aesthetic: Use #FFFFF0 (Ivory) with brown or gold elements.
• For a clean, professional feel: Pair #F8F8FF (Ghost White) with navy blue or dark green.

3. Creating a Light Mode/Dark Mode Toggle

For a better user experience, consider offering both light mode and dark mode options. Here’s a simple way to toggle between an off-white and dark background using JavaScript:

<button id="toggleTheme">Toggle Dark Mode</button>

<script>
document.getElementById('toggleTheme').addEventListener('click', function() {
    document.body.classList.toggle('dark-mode');
});
</script>

<style>
body {
    background-color: #FAFAFA;
    color: #333;
    transition: background 0.3s ease, color 0.3s ease;
}

.dark-mode {
    background-color: #222;
    color: #FAFAFA;
}
</style>

This allows users to switch between a light and dark background based on their preference, making your website more user-friendly.

Conclusion

Selecting the right background color is a critical aspect of web design that directly impacts user experience. While pure white may seem like a default choice, it can be too bright and cause eye fatigue. By using off-white shades like #FAFAFA (Snow) or #F2F2F2 (Alabaster), you can create a more comfortable, readable, and visually appealing website.

If you’re designing a website with readability and user comfort in mind, consider switching to a soft white background for a better overall experience. Whether you’re working on a personal blog, an e-commerce site, or a corporate webpage, the right color choices can make a significant difference in user engagement and satisfaction.

Choosing the Right Off-White Colors for a Comfortable Website Background was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Imagine this: you run a coffee shop called BrewCafe, and you need some ingredients from a supplier called CoffeeBeansInc. You send a request for beans, but they don’t respond. Why? Because the supplier doesn’t recognize you and won’t share their beans without permission.

This is the basic idea behind CORS (Cross-Origin Resource Sharing). Let’s break it down step by step!

What is CORS?

CORS is a security rule built into browsers. It ensures that one website cannot access data from another website without permission.

The browser will block a request if:

1. The origin of the request (e.g., brewcafe.com) is different from the origin of the server receiving the request (e.g., api.coffeebeansinc.com).
2. The server hasn’t granted permission to share the data.

The browser acts as a gatekeeper, making sure that only authorized requests can go through.

Example Problem

1. BrewCafe is hosted at https://brewcafe.com.
2. They try to fetch ingredient data from their supplier’s API at https://api.coffeebeansinc.com.
3. The browser notices that the origins (the domain names) are different.

As a result, the browser blocks the request with an error like this:

Access to fetch at ‘https://api.coffeebeansinc.com’ from origin ‘https://brewcafe.com’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present.

This means the server at CoffeeBeansInc didn’t provide the necessary permission for BrewCafe to access the data.

Why is CORS Important?

CORS is a safety feature. Without it, malicious websites could abuse a browser’s ability to make requests.

For example, imagine you’re logged into your online banking account (banking.com). Without CORS, a harmful website could potentially send requests to banking.com using your credentials, accessing sensitive information or transferring money without your permission.

CORS helps protect users from this kind of threat by enforcing a rule called the Same-Origin Policy. This rule says:

• Only websites from the “same house” (same domain, protocol, and port) can exchange data.

How Does CORS Work?

For BrewCafe to successfully access data from CoffeeBeansInc, the server at CoffeeBeansInc needs to say, “Yes, it’s okay for you to fetch this data.”

The server grants permission by sending a special note called a CORS header.

How to Fix a CORS Error

When you encounter a CORS issue, it means the server isn’t sending the necessary permissions. Here’s how to fix it:

1. Add the Right Headers on the Server

The server needs to send headers to grant permission:

Allow any origin:

Access-Control-Allow-Origin: *

This allows requests from any website.

Allow only specific origins:

Access-Control-Allow-Origin: https://brewcafe.com

This is more secure, as it only allows a specific website to access the data.

2. Handle Preflight Requests

When making more complex requests (such as POST, PUT, or custom headers), the browser sends a preflight request before the actual request. This is done using the OPTIONS method. It’s like asking the server, “Hey, are you okay with this request?”

For example, if BrewCafe tries to send a POST request with custom headers, the browser first sends an OPTIONS request to CoffeeBeansInc to check if the server allows such requests.

The server needs to respond with the following headers to indicate it’s okay to proceed:

Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization

This tells the browser that the server is okay with the methods (GET, POST, OPTIONS) and headers (Content-Type, Authorization) the frontend intends to use.

3. Use a Proxy for Local Development

During local development, if the backend server isn’t yet set up to handle CORS, you can use a proxy. This acts as a middleman to forward requests from your frontend to the backend, making it appear as though they are from the same origin.

CORS Can’t Be Bypassed

While you might be tempted to use browser extensions or modify browser settings to bypass CORS during development, these are not solutions for production environments.

The proper way to fix CORS issues is to configure the server correctly to handle the requests.

Conclusion

CORS is a mechanism that protects your data while making sure that only authorized websites can interact with your server.

If you encounter a CORS error:

1. Don’t panic — this is not a bug in your browser.
2. Fix it by adding the correct headers on the server.
3. Understand that CORS is an important security measure for protecting users online.

With the right setup, communication between BrewCafe and CoffeeBeansInc will run smoothly, and you can get the ingredients you need without any issues! ☕️

Additional Notes

Be cautious when using Access-Control-Allow-Origin: * in production environments. Allowing all origins to access your server can be risky, as it opens the door to any website making requests to your server, potentially leading to security vulnerabilities. It’s generally safer to specify trusted domains that are allowed to make requests.

CORS: Why Browsers Block Requests and How to Fix it was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this guide, we’ll walk through the steps to create a Dockerized Laravel 11 application with a MySQL database. We’ll use docker-compose to set up the application and database services, and configure Apache with PHP to serve the Laravel application.

Step 1: Create the Dockerfile

The Dockerfile defines the steps needed to set up the environment for our Laravel application. It installs the necessary PHP extensions, configures Apache, and installs Composer to manage dependencies.

Dockerfile

# Use PHP image with Apache
FROM php:8.2-apache

# Copy customized Apache configuration
COPY 000-default.conf /etc/apache2/sites-available/000-default.conf

# Install required system dependencies
RUN apt-get update && apt-get install -y \
    libpng-dev \
    libjpeg-dev \
    libfreetype6-dev \
    zip \
    unzip \
    git \
    curl \
    libzip-dev \
    libicu-dev \
    ca-certificates \
    lsb-release \
    gnupg \
    && docker-php-ext-configure gd --with-freetype --with-jpeg \
    && docker-php-ext-install gd pdo pdo_mysql intl zip

# Install Node.js and npm
RUN curl -sL https://deb.nodesource.com/setup_18.x | bash - \
    && apt-get install -y nodejs

# Enable Apache mod_rewrite
RUN a2enmod rewrite

# Copy application into the image
COPY . /var/www/html

# Set working directory
WORKDIR /var/www/html

# Install Composer
COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

# Install Composer dependencies
RUN git config --global --add safe.directory /var/www/html
RUN composer install --no-interaction --no-plugins --no-scripts --prefer-dist

# Set file ownership for Apache
RUN chown -R www-data:www-data /var/www/html
RUN chown -R www-data:www-data /var/www/html/storage /var/www/html/bootstrap/cache
RUN chmod -R 775 /var/www/html/storage /var/www/html/bootstrap/cache

# Expose port 80
EXPOSE 80

Explanation of the Dockerfile:

1. PHP 8.3 with Apache: We start from the official PHP 8.3 Apache image.
2. Install PHP Extensions: We install common PHP extensions needed by Laravel, such as GD, PDO, and MySQL.
3. Enable mod_rewrite: This allows us to use Laravel’s route handling.
4. Install Composer: We copy the latest Composer binary into the image to manage Laravel’s dependencies.
5. File Permissions: Ensure the correct file permissions for Laravel’s storage and cache directories.
6. Expose Port 80: Expose the default HTTP port for the web server.

Step 2: Create the docker-compose.yml

Next, we’ll configure docker-compose.yml to define the application and database services. docker-compose allows us to easily manage multi-container applications.

docker-compose.yml

services:
    app:
        build: .
        ports:
            - "9000:80" # Port to access the application from the browser
        volumes:
            - .:/var/www/html # Mount local application folder to container
            - /var/www/html/storage # Storage for Laravel's storage folder
            - /var/www/html/bootstrap/cache # Storage for Laravel's cache
        networks:
            - app_network
        mem_limit: "2G"
        cpus: "1"
        environment:
            - VIRTUAL_HOST=localhost # Use localhost for local development

    db:
        image: mysql:8.0
        environment:
            MYSQL_DATABASE: database
            MYSQL_ROOT_PASSWORD: password
        ports:
            - "3307:3306" # Port to access MySQL
        volumes:
            - db_data:/var/lib/mysql # MySQL data storage
        networks:
            - app_network
        mem_limit: "2G"
        cpus: "1"

volumes:
    db_data:

networks:
    app_network:
        driver: bridge

Explanation of docker-compose.yml:

1. App Service:

• build: . tells Docker to build the image using the current directory's Dockerfile.
• The app will be available on localhost:9000, as we map port 9000 on the host to port 80 in the container.
• We mount the application directory and the vendor directory to persist the Composer dependencies.

2. Database Service:

• We’re using the official mysql:8.0 image.
• The database will have a user, password and database from laravel .env.
• We map MySQL’s default port 3307 from the container to the host.
• We store the MySQL data in a named volume (db_data) to persist the database.

3. Networks:

We create a bridge network app_network to ensure that the app and database services can communicate with each other.

Step 3: Create Apache Virtual Host Configuration (000-default.conf)

In this step, we configure Apache to serve the Laravel application. The configuration will ensure that requests are routed correctly and that the .htaccess file works for URL rewriting.

000-default.conf

<VirtualHost *:80>
    DocumentRoot /var/www/html/public

    <Directory /var/www/html>
        AllowOverride All
        Order Allow,Deny
        Allow from All
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Explanation:

• DocumentRoot: We set the document root to /var/www/html/public because that’s where Laravel's index.php file is located.
• AllowOverride All: This allows the .htaccess file to be used for URL rewriting, which is important for Laravel's routing.

Step 4: Build and Start the Docker Containers

Now, let’s build and start the containers. In your terminal, run the following commands:

• Build the Docker containers:

docker-compose build

• Start the containers in the background:

docker-compose up -d

• The application will now be accessible at http://127.0.0.1:9000, and the MySQL database will be running on port 3307.

Step 5: Stopping the Containers

To stop the containers and remove the volumes (which contain the database data), use the following command:

docker-compose down

This will stop and remove all the containers, networks, and volumes defined in the docker-compose.yml file. You can also use docker-compose down --volumes if you want to remove the volumes (like the database data).

Step 6: Accessing the Database

To connect to the MySQL database, you can use a database management tool like HeidiSQL. Use the following credentials as defined in the docker-compose.yml file:

• Host: db
• Port: 3307
• Username: root
• Password: password
• Database: database

Cleaning Up Unused Docker Resources

To clear unused Docker resources, such as stopped containers, unused networks, and dangling images, you can run:

docker system prune -f

This will:

• Remove all stopped containers.
• Remove unused networks.
• Remove dangling images (images that are not tagged and not used by any container).
• It will not remove volumes unless you specify --volumes.

Note: Use docker system prune with caution, as it will remove resources that are no longer being used, potentially freeing up disk space. Make sure you don't need those resources before running this command.

Rebuild the containers

docker-compose up --build -d

This will rebuild the images, recreate the containers, and start them again in the background.

Alternative Approach (If you only want to rebuild a specific service):

If you only want to rebuild a specific service (for example, just the app container), you can specify the service name:

docker-compose up --build -d app

This command will rebuild and restart the app service only, without affecting the database container.

Access the container using docker-compose

To access the Docker container running your application, you can use the docker exec or docker-compose exec command, depending on whether you're using Docker Compose or Docker directly.

Check if the container is running: To verify if your container is running, use:

docker-compose ps

If the app container is listed, proceed to the next step.

Enter the container: To enter the app container, use the following command:

docker-compose exec -it app bash

This will open a terminal session inside the container, where you can run commands as needed.

or check this github repo for example.

Setting Up a Laravel 11 with Docker was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Webmin is a powerful web-based interface that allows you to manage various system configurations on a Linux server. If you’re using PHP 8.3 on your server and need to enable PHP extensions, this detailed guide will walk you through the steps to activate them, check which php.ini is active (for CGI, CLI, or FPM), and restart necessary services using Webmin.

Prerequisites

• Webmin is installed and accessible on your server.
• PHP 8.3 is installed on your server. (You can use any php version)
• You have the required root or sudo permissions to configure PHP and Webmin.

In this tutorial, I’m using Webmin 2.202 on Ubuntu Linux 20.04.6. Please note that different versions of Webmin or other operating systems may result in slightly different interfaces or steps.

Step 1: Log in to Webmin

Access Webmin: Open your browser and go to your Webmin login page. Typically, the URL will be

https://your-server-ip:10000

Login: Enter your username and password for Webmin. This is usually the root user or a user with sudo privileges.

Step 2: Access PHP Configuration in Webmin

Navigate to PHP Configuration:

Once you are logged in, from the Webmin dashboard, click on Tools > PHP Configuration under the Servers section. This will take you to the PHP configuration page where you can manage different PHP versions.

On the PHP Configuration page, you will see a list of PHP versions installed on your system.

Step 3: Enable PHP Extensions

Edit the PHP Configuration:

After selecting PHP 8.3, click on Edit Manualy. This will open the configuration file (php.ini) used by PHP 8.3.

Search for the Extension:

In the php.ini file, look for the line corresponding to the extension you want to enable. For example, to enable the intl extension, search for:

;extension=intl

Uncomment the Extension:

If the extension is commented out (with a semicolon ;), remove the semicolon at the beginning of the line to uncomment it:

extension=intl

Install the Extension (if needed):

If the extension is not installed on your server, you will need to install it manually. Open a terminal or use SSH to connect to your server and run the following command:

sudo apt install php8.3-intl

This will install the intl extension for PHP 8.3. You can replace intl with the name of any other extension you wish to enable (e.g., mbstring, xml, etc.).

Step 4: Restart PHP and Web Server

• Restart PHP Using Webmin: After enabling the extension, go back to the Webmin PHP Configuration page. At the top, click Restart or Apply Changes to apply the configuration changes to PHP 8.3.
• Restart the Web Server: To ensure the new configuration is loaded, restart the web server. Depending on your server setup, the following options are available:
• For Apache: If you are using Apache, you can restart it directly from Webmin by navigating to Webmin > Dashboard > Servers Status and clicking Restart Apache.

• For PHP-FPM: If you’re using PHP-FPM for Apache or Nginx, you can restart the PHP-FPM service:

sudo systemctl restart php8.3-fpm

Step 5: Verify the PHP Extension

• Create a PHP Info File: To confirm that the extension has been enabled, you can create a PHP info file. Create a new PHP file (e.g., info.php) and place the following code in it:

<?php phpinfo(); ?>

• Access the PHP Info File: Upload or place the info.php file in your web server's document root. Then, open your web browser and navigate to http://your-server-ip/info.php (replace your-server-ip with the IP address of your server).
• Check for the Extension: In the phpinfo() page, search for the enabled extension (e.g., intl). If it appears in the list, it means the extension has been successfully enabled.

Check Which php.ini Is Active (CLI, CGI, FPM)

If you’re using multiple PHP configurations (CGI, CLI, or FPM), you may want to check which php.ini file is being used by each PHP handler. Here’s how to check for each:

1. Check PHP CLI (php.ini)

To see which php.ini is being used for PHP CLI (Command Line Interface), run the following command:

php8.3 --ini

This will return output like:

Configuration File (php.ini) Path: /etc/php/8.3/cli
Loaded Configuration File: /etc/php/8.3/cli/php.ini

2. Check PHP FPM (php.ini)

For PHP running with PHP-FPM, use this command to check the php.ini being loaded:

php-fpm8.3 -i | grep "Loaded Configuration File"

This will output something like:

Loaded Configuration File => /etc/php/8.3/fpm/php.ini

3. Check PHP CGI (php.ini)

For PHP running as CGI, use the following command:

php-cgi8.3 -i | grep "Loaded Configuration File"

This will return the path to the php.ini for PHP CGI:

Loaded Configuration File => /etc/php/8.3/cgi/php.ini

Once you have verified that the extension is enabled and the correct php.ini file is active, remember to delete or secure the info.php file to prevent unauthorized access to your PHP configuration details.

This guide should help you enable PHP extensions and check your PHP configuration in Webmin. If you have any questions or need further assistance, feel free to ask! 😊

For more details about Webmin, check out this link.

How to Enable PHP Extensions in Webmin was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is Laravel Sanctum?

API authentication is essential for controlling access to your application’s resources. Laravel Sanctum is a simple, lightweight authentication package perfect for Single Page Applications (SPAs) and mobile apps that need token-based authentication without the complexity of OAuth. In this article, we’ll walk through setting up user registration, login, and logout using Laravel 11 and Sanctum.

Getting started

First, open Terminal and run the following command to create a fresh laravel project:

laravel new sanctum

After done creating new laravel project, go inside sanctum-auth directory and run the app

cd sanctum
php artisan serve

This command will start the server, usually available at http://127.0.0.1:8000. Verify that the application loads correctly in your browser.

Configure Database

In the .env file, set up your database credentials:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=sanctum
DB_USERNAME=postgres
DB_PASSWORD=pwapp

Installation and Setup

Next, install Laravel Sanctum using Composer:

php artisan install:api

To allow users to create API tokens, add the HasApiTokens trait to the User model.

Open app/Models/User.php and modify it as follows:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Laravel\Sanctum\HasApiTokens;

class User extends Authenticatable
{
    use HasFactory, Notifiable, HasApiTokens;
}

Adding the HasApiTokens trait enables token-based authentication for this model, allowing users to generate personal access tokens.

For more detailed information about sanctum, kindly check this documentation.

Set Up Authentication Routes

Define authentication routes in routes/api.php. These routes will handle user registration, login, and logout.

<?php

use Illuminate\Support\Facades\Route;

Route::prefix('auth')->name('auth.')->group(function () {
    Route::middleware('throttle:5,1')->group(function () {
        Route::post('register', [App\Http\Controllers\AuthController::class, 'register'])->name('register');
        Route::post('login', [App\Http\Controllers\AuthController::class, 'login'])->name('login');
    });

    Route::middleware('auth:sanctum')->group(function () {
        Route::post('logout', [App\Http\Controllers\AuthController::class, 'logout'])->name('logout');
    });
});

Create the AuthController

Now, create an AuthController to handle registration, login, and logout logic:

php artisan make:controller AuthController

In app/Http/Controllers/AuthController.php, implement the methods as follows:

<?php

namespace App\Http\Controllers;

use App\Models\User;
use Illuminate\Http\JsonResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\Facades\Hash;

class AuthController extends Controller
{
    public function register(Request $request): JsonResponse
    {
        $data = $request->validate([
            'name'      => 'required|string',
            'email'     => 'required|string|email|unique:users,email',
            'password'  => 'required|string|min:8|confirmed|regex:/[a-z]/|regex:/[A-Z]/|regex:/[0-9]/',
        ]);

        $user = User::create([
            'name'      => $data['name'],
            'email'     => $data['email'],
            'password'  => Hash::make($data['password'])
        ]);

        $token = $user->createToken('user-token')->plainTextToken;

        $response = [
            'user'  => $user->makeHidden(['password', 'remember_token']),
            'token' => $token
        ];

        return response()->json($response, 201);
    }

    public function login(Request $request): JsonResponse
    {
        $request->validate([
            'email'     => 'required|string|email',
            'password'  => 'required|string|min:8'
        ]);

        $user = User::where('email', $request->email)->first();

        if (!$user || !Hash::check($request->password, $user->password)) {
            return response()->json([
                'message' => 'These credentials do not match our records.'
            ], 401);
        }

        $token = $user->createToken('user-token')->plainTextToken;

        $response = [
            'user'  => $user->makeHidden(['password', 'remember_token']),
            'token' => $token
        ];

        return response()->json($response, 200);
    }

    public function logout()
    {
        Auth::user()->tokens->each(function ($token) {
            $token->forceDelete();
        });

        return response()->json([
            'message' => 'Logged out successfully',
        ], 200);
    }
}

Test the Authentication API

You can test the API endpoints with a tool like Postman or cURL.

1. Register a New User

• Endpoint: POST /api/auth/register
• Body: name, email, password, password_confirmation

2. Log In to Get an Access Token

• Endpoint: POST /api/auth/login
• Body: email, password

3. Log Out

• Endpoint: POST /api/auth/logout
• Header: Authorization: Bearer your_generated_token
• This will invalidate the token, logging the user out.

See the postman api docs here

Conclusion

With this setup, you have a secure, token-based authentication system for your Laravel 11 API using Sanctum. This foundation allows you to build APIs that only authenticated users can access, making it ideal for SPAs, mobile apps, and even basic server-to-server communication.

Sanctum’s simplicity makes it a great choice for applications where you want to avoid the complexity of OAuth, while still providing strong security and flexibility. You can further extend this setup to add roles, permissions, and additional features as needed.

Laravel 11 Sanctum: Secure Your API with Token-Based Authentication was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Laragon is a powerful and lightweight local development environment that supports various databases, including MySQL, MariaDB, and PostgreSQL. This guide will walk you through the process of adding PostgreSQL to your Laragon setup, allowing you to build projects that require a PostgreSQL database.

What You’ll Need:

• Laragon installed: If you haven’t installed Laragon yet, you can download it from the official website.
• PostgreSQL binaries: You’ll need to download the PostgreSQL installer for Windows.

Steps to Add PostgreSQL to Laragon:

1. Download PostgreSQL Binaries

• Visit the PostgreSQL Binaries download page.
• Choose the appropriate version (e.g., postgresql-17.0-1-windows-x64-binaries.zip) and download it to your computer.

2. Extract PostgreSQL Binaries to Laragon’s bin Folder

• Navigate to your Laragon installation directory (usually C:\laragon).
• Inside the Laragon directory, open the bin folder.
• Create a new folder named PostgreSQL if it doesn’t already exist.
• Extract the downloaded zip file into the PostgreSQL folder.

3. Select PostgreSQL Version

• Right-click on the Laragon icon in the taskbar.
• From the context menu, hover over PostgreSQL.
• Point your cursor to Version and select the version of PostgreSQL you want to use.

4. Start PostgreSQL

• In Laragon, click Start All to start all services.
• You should see PostgreSQL listed among the services. Click Start next to PostgreSQL to activate it.

5. Test PostgreSQL

• To check if PostgreSQL is running correctly, open Laragon’s Terminal and type the following command:

psql -U postgres

• If the PostgreSQL command-line interface opens and allows you to interact with the database, PostgreSQL has been successfully set up.

6. Connect PostgreSQL to Your Projects

• To use PostgreSQL in your Laravel project, update your .env file to configure the database connection:

DB_CONNECTION=pgsql
DB_HOST=127.0.0.1
DB_PORT=5432
DB_DATABASE=your_database_name
DB_USERNAME=postgres
DB_PASSWORD=your_password

Conclusion

By following these steps, you’ll have PostgreSQL up and running in Laragon. Whether you’re working on a Laravel project or another application that requires PostgreSQL, Laragon’s simple setup and PostgreSQL support make it an ideal tool for local development.

Happy coding, and enjoy working with PostgreSQL in Laragon!

How to Add PostgreSQL to Laragon was originally published in Towards Dev on Medium, where people are continuing the conversation by highlighting and responding to this story.