Accessing ServBay Local Development Environment over a LAN

For small development teams or individual developers needing to test across multiple devices, being able to access the ServBay local development environment of another member or device within the same LAN is a common and important requirement. ServBay is designed so that most core services can be accessed via LAN, but some services require additional configuration to ensure both security and availability.

This article provides a detailed guide on how to configure and access websites and database services in ServBay from your LAN.

Prerequisites

Before attempting to access ServBay services over your LAN, ensure the following requirements are met:

1. Network Connection: The computer providing ServBay services (hereafter "host machine") and the visitor's computer (hereafter "client") must be on the same LAN.
2. Host Machine IP Address: You need to know the internal LAN IP address of the host machine. This can be found in the network settings of the host device.
3. Firewall Configuration: If a firewall is enabled on the host machine, you must allow external connections to the key ports used by ServBay (for example, HTTP is typically 80, HTTPS is 443, MySQL is 3306, PostgreSQL is 5432, Redis is 6379, etc.). Open the appropriate ports in your firewall settings depending on which services you want to make accessible, and configure Access Control Lists (ACL) to limit which IP addresses are allowed to connect if needed.

Website

By default, local websites configured via ServBay typically listen on all network interfaces of the host machine (i.e., 0.0.0.0 or *), allowing other devices on the LAN to access them out of the box. ServBay uses Caddy or Nginx as its web server, both of which are usually set up this way by default.

However, for visitors to access these websites via domain names on their browsers, their systems need to have domain DNS resolution correctly configured. In addition, if your local website uses SSL certificates generated by ServBay (highly recommended), visitors must also install the ServBay root certificate to avoid browser warnings.

Here's an example configuration scenario:

• Host machine LAN IP: 10.0.0.3
• ServBay website domain: servbay.demo
• Website root directory: /Applications/ServBay/www/servbay.demo

Configuring Domain Name Resolution (DNS)

Client devices need to resolve the domain servbay.demo to the host machine's IP address 10.0.0.3. There are two common methods:

1. Edit the client's Hosts file: This is the simplest and most direct method, suitable for a small number of client devices.

   • Locate the Hosts file on the client device:
     • macOS/Linux: /etc/hosts
     • Windows: C:\Windows\System32\drivers\etc\hosts
   • Open the Hosts file with administrative privileges and add the following line at the end:

     10.0.0.3    servbay.demo

   • Save the file. Now, when the client device accesses servbay.demo, it will resolve to 10.0.0.3.

2. Configure on the LAN DNS server: If your LAN has its own DNS server (for example, a router with DNS capabilities, or a dedicated DNS service), you can add an A record for servbay.demo pointing to the host machine's IP address 10.0.0.3. With this setup, all devices using that DNS server in your LAN will be able to resolve the domain.

Distributing and Installing ServBay User Root Certificate (SSL)

ServBay provides a powerful PKI feature for the local development environment, generating its own root certificate (ServBay User CA) to sign SSL certificates for local sites. To avoid security warnings when clients access HTTPS sites using these certificates, they need to trust the ServBay User CA.

You need to export the ServBay User CA and distribute it to LAN users, instructing them to install and trust this root certificate in their operating system or browser.

Refer to the relevant SSL certificate management sections in the ServBay documentation, especially Exporting the Certificate and Installing in the OS/Browser for detailed steps.

Database

ServBay supports multiple database services, including MySQL, MariaDB, PostgreSQL, and MongoDB, as well as in-memory databases like Redis and Memcached. The default network listening settings and authentication methods vary for each database.

MySQL / MariaDB

In ServBay, MySQL and MariaDB are configured by default to listen on all network interfaces (0.0.0.0), which means they are accessible from the LAN out of the box.

However, MySQL/MariaDB enforces strict user authentication. Even if network access is open, visitors must use a username and password authorized to connect from their IP address.

By default, the root user is typically restricted to connecting only from 127.0.0.1 or localhost. To allow LAN access, create a new database user or modify permissions for an existing user, allowing connections from specific LAN IPs or any address (%).

For example, to create a user named servbay-demo who can connect from any LAN IP (%) with proper privileges:

-- Assuming you are logged in as root or a user with sufficient privileges
CREATE USER 'servbay-demo'@'%' IDENTIFIED BY 'your_strong_password';
GRANT ALL PRIVILEGES ON `your_database_name`.* TO 'servbay-demo'@'%';
FLUSH PRIVILEGES;

Replace 'your_strong_password' and your_database_name as needed.

Important Note: Allowing users to connect from any IP (%) and granting broad privileges poses security risks. In production or untrusted LAN environments, it is strongly recommended to restrict users to only connect from specific trusted IP addresses (such as 'servbay-demo'@'10.0.0.5'), or use more secure connection methods such as VPN.

ServBay supports resetting the root password for MySQL and MariaDB. To manage user permissions, you can use this feature or operate via client tools.

Redis

By default, Redis in ServBay listens only on the localhost (127.0.0.1), which means it does not allow LAN connections. This is for security reasons, as Redis does not enable password authentication by default.

To allow LAN access to Redis, you need to modify the Redis configuration file redis.conf.

You have two options:

1. Using the ServBay UI

• Open ServBay and navigate to Database - Redis in the left sidebar.
• In the configuration panel on the right, check Require Password and enter a password in the field provided.
• Click Save.

2. Manually edit the redis.conf file (not recommended)

1. Locate the Redis configuration file in ServBay (usually under the installation directory, e.g., /Applications/ServBay/etc/redis/redis.conf).
2. Open redis.conf with a text editor.
3. Find the line bind 127.0.0.1.
4. Change it to bind 0.0.0.0, or comment it out (# bind 127.0.0.1) to have Redis listen on all network interfaces.
5. [Extremely Important] Locate the requirepass line (it may be commented out). Uncomment it and set a strong password:

   requirepass your_very_strong_redis_password

   Never expose Redis to LAN or public networks without setting a password. This poses significant security risks!
6. Save the redis.conf file.
7. Restart the Redis service within the ServBay application for changes to take effect.

Clients can now connect to your Redis service using the host's LAN IP address and the password you set.

PostgreSQL

PostgreSQL in ServBay by default also listens only on localhost (127.0.0.1), so LAN access is not allowed out of the box.

To allow LAN access, you need to modify two key configuration files: postgresql.conf and pg_hba.conf.

1. Locate the configuration files for PostgreSQL in ServBay (usually under the installation directory, e.g., /Applications/ServBay/etc/postgresql/postgresql.conf and /Applications/ServBay/etc/postgresql/pg_hba.conf).

2. Edit postgresql.conf:

   • Open postgresql.conf with a text editor.
   • Find the listen_addresses line (it may be commented out).
   • Uncomment it and set its value to '*' so PostgreSQL listens on all network interfaces:

     listen_addresses = '*'

   • Save the file.

3. Edit pg_hba.conf:

   • Open pg_hba.conf with a text editor. This file controls which hosts, users, and databases are permitted, and which authentication methods are used.
   • Add a line to allow LAN connections. For example, to permit all users from the 10.0.0.0/24 subnet to connect to any database with password authentication:

     # TYPE  DATABASE        USER            ADDRESS                 METHOD
     host    all             all             10.0.0.0/24             md5

     • TYPE: host means TCP/IP connection.
     • DATABASE: all allows connections to all databases (you can specify a database name).
     • USER: all allows all database users (you can specify a username).
     • ADDRESS: 10.0.0.0/24 (example) allows connections from 10.0.0.1 to 10.0.0.254. You can specify a single IP or use 0.0.0.0/0 to allow all IPv4 addresses (not recommended unless protected by a firewall).
     • METHOD: md5 requires clients to use MD5-encrypted passwords (the recommended authentication for remote connections). Other options such as trust (no password, never use for remote connections) or password (plaintext, insecure) should be avoided.
   • Save the file.

4. Restart the PostgreSQL service within the ServBay application to apply changes.

Clients can now connect to PostgreSQL using the host's LAN IP address, a valid PostgreSQL username, and password.

ServBay supports resetting the PostgreSQL root (postgres) password. To manage user permissions, you can use this feature or operate via client tools.

Memcached

Memcached is a high-performance distributed memory object caching system, designed to be simple and does not provide built-in authentication or authorization.

As such, it is strongly discouraged to expose Memcached directly to your LAN or public networks unless you have other network security measures in place (for example, restricting access to trusted internal services only, and controlling access through firewalls).

You can configure Memcached in ServBay to listen on the LAN IP, but be aware of the security risks this entails. By default, Memcached only listens on localhost. To change the listen address, edit Memcached’s configuration much like you do for Redis—but remember, it has no password protection.

Security Considerations

Opening your local development environment to the LAN is convenient for collaboration and cross-device testing, but it also introduces security risks. Please keep the following best practices in mind:

• Firewall: Always use a firewall to restrict access to open ports on the ServBay host. Only allow connections from trusted LAN IP ranges.
• Strong Passwords: Set strong passwords for databases (MySQL/MariaDB/PostgreSQL) and Redis. Update passwords regularly.
• Principle of Least Privilege: Grant database users the minimum permissions necessary. Avoid using broad-privileged root or postgres users for routine remote access.
• Memcached Security: Once again, since Memcached lacks built-in security, take extra caution when exposing it on the LAN. Consider using SSH tunneling or other secure access methods.
• OS Updates: Keep the host machine’s operating system, ServBay itself, and all related packages up to date for the latest security patches.

By following these steps and security guidelines, you can safely and efficiently share and access your ServBay local development environment within your LAN.