Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

kennedystephen's avatar

Load Balancing of Authentication and Session, Without Opening Firewall

We’ve created our first Laravel web application. We’ve wired up basic Laravel authentication. Our application also relies on session storage. We’ve been hosting our application on a single web server. So far, everything is working great!

For scalability purposes, we've now moved our web application onto 2 web servers, and setup a load balancer to dynamically route traffic requests between each server. This is where things broke down: it seems session cache and authentication storage are stored locally, per server. For instance, we’ve been using the default SQL Lite file for authentication storage. We’ve been using ‘file’ based configuration for session storage as well. So when users get dynamically bounced back-and-forth between servers, session and authorization become inconsistent and become unreliable.

We’ve attempted to switch both the authentication and session storage to be driven off a shared SQL server instance. But we are concerned that this opens a direct connection between our web server and the SQL server. Meaning, our web application server is publically accessible, but our SQL server sits inside our network. We’d rather not open a firewall hole between these two. Is there a better approach?

Our traditional stack is .NET. In that stack, we tend to have a web application server that hosts custom API endpoints that talk directly to the database, and these APIs just process requests for specific institutional data. While I know Laravel has API capabilities, I cannot imagine it easily allows for “custom API” to facilitate intrinsic authentication and session handling. Also, using memcached or redis doesn’t really help this issue, since I’m not only talking about storing session information, but also Authentication. And default Laravel authentication choices for persistency doesn’t include those items. I am highly hesitant to go too far outside the Laravel provided default choices for persistent storage.

What is the best approach to configure Laravel to manage both session and authentication based on shared persistence storage? Is there a way to limit opening firewall ports/holes between our web application servers, and the backend SQL storage?

We've read and reviewed quite a number of online articles, previous tickets, etc. But none of them directly talk about this specific issue.

Any help or guidance would be appreciated. Thank you.

0 likes
6 replies
Cronix's avatar

This should help a lot: https://serversforhackers.com/c/so-you-got-yourself-a-loadbalancer

In short, you have to separate everything and store nothing locally. Both servers should be using a common store for everything. Both pointing to the same database, using S3 to store images/assets instead of on the individual boxes, etc. You'd want to use the database or (better) redis for your sessions. Then both machines have access to the exact same data as it's not specific to the box their currently on.

This way, it doesn't matter what machine the user is on.

What is the best approach to configure Laravel to manage both session and authentication based on shared persistence storage? Is there a way to limit opening firewall ports/holes between our web application servers, and the backend SQL storage?

We have our infrastructure in amazon. Everything is behind a firewall and the servers talk to each other behind that using the private network. The only thing that's publicly exposed is the load balancer and all public traffic uses that.

1 like
kennedystephen's avatar

@Cronix Thank you so much. I really do appreciate any information. The content in that article seems to be specific to using a shared persistant storage (like Redis or AWS something) directly from the web server.

We don't use S3, but I get your point on using the same database. At this time, we'd prefer to use on-premise storage, primarily SQL.

I am hesitant to use a shared database server for authentication or session, because my Laravel web application would have to have a direct line of communication to my backend SQL server(s). I'm under the assumption that it's not a good practice to allow your public facing web server to talk directly to any internal resource, such as an internal SQL server

Using redis for session storage is an option, but I think I have the same problem. I'd have to either host redis externally (in dmz), or in some other way punch a hole through the firewall to allow direct communication between my web server and my internal Redis server.

Can you elaborte more on "Everything is behind a firewall and the servers talk to each other behind that using the private network."

Thoughts?

SapporoGuy's avatar

If you have a load balancer then that is what is public facing. Behind the load balancer and firewall are your Laravel Servers, DB server, storage server and Redis server. So, if my network understanding is correct, you should be ok with Laravel talking to the DB server.

You might need to use sticky sessions on the load balancer. I think it's better to keep users on one specific Laravel server rather than having them jump between Laravel servers randomly.

1 like
kennedystephen's avatar

@SapporoGuy Thank you so much for your reply.

You're right, I would be ok with our Laravel web servers talking to our SQL servers if both were behind the firewall. I would agree that our load balancer might be public facing, but it seems odd to me to have our web servers internal, and not external.

We've also thought about sticky sessions on load balancer to ensure traffic doesn't bounce between the two servers, but we thought that limited the value of why we want to have that balancer. For instance, if we suddenly chose to bring down 1 of those servers, we'd want the traffic to be re-routed to the second server, and the user's experience not be disrupted.

Thoughts?

Cronix's avatar

I would agree that our load balancer might be public facing, but it seems odd to me to have our web servers internal, and not external.

For all intents and purposes, the load balancer IS all of the app servers. It's a proxy. It just directs the traffic to the servers.

internet -> load balancer (public IP) -> app servers (private ip's)

Then the app servers communicate with the db(s) and other services, which are also private ip's.

1 like
SapporoGuy's avatar

@cronix knows about this probably better than I do.

To add to his answer, the load balancer pings the servers to check for cpu usage basically, it redirects traffic to the less congested server. So, this means that if you do pull down a server like doing a VSTS release, the load balancer will send the traffic to the available server(s).

yeah, running a load balancer as the public facing machine is weird. I still haven't figured out yet.

As for the sticky persistence. I had needed it to prevent logouts. Play with the value. I wouldn't set it at first but you might notice weird session behavior.

I didn't really emphasis this enough, you should consider what you are doing with images and uploads. Running another machine or dedicate storage device is really handy. You don't have to worry about syncing and what not. You could also run a server to act as a caching device for media.

Please or to participate in this conversation.