When an administrator opens remFREE in a browser, several components participate before the requested page or action reaches the managed endpoint.
Understanding this path makes the platform much easier to troubleshoot.
Browser traffic begins with HTTPS
The technician accesses:
https://rmm.remfree.com
The browser establishes an encrypted HTTPS connection to the remFREE web service.
Apache provides the public-facing web-server layer for the Laravel application.
Apache
Apache handles the incoming HTTP and HTTPS request path.
It is responsible for web-server concerns such as:
- virtual-host handling
- TLS termination
- serving the Laravel public directory
- passing PHP application requests into the PHP runtime
- supporting reverse-proxy behavior where required
Apache is the front door to all requests.
Laravel
Laravel handles the application's business logic.
After a request reaches the application, Laravel can make decisions involving:
- authentication
- authorization
- tenant membership
- routes
- controllers
- devices
- jobs
- inventory
- compliance
- patch management
- account settings
- activity
- auditing
For example, opening a device page is fundamentally an application request.
Laravel determines which device the user is allowed to see and retrieves the relevant information.
MariaDB
Persistent application state lives in the database.
Examples include:
- tenants
- users
- devices
- jobs
- inventory
- compliance results
- events
- configuration
Laravel is responsible for interpreting that data in the context of the application.
A normal browser request
A simplified page request looks like:
Technician Browser
|
| HTTPS
v
Apache
|
v
Laravel / PHP
|
v
MariaDB
|
v
Laravel renders
|
v
Apache
|
v
Browser
That path is well suited to normal application pages and API operations.
Real-time communication takes a different path
The endpoint agent has different communication requirements.
It needs a persistent connection.
That work is handled by the Go gateway.
Conceptually:
Browser requests
|
v
Apache
|
v
Laravel
Agent connection
|
v
WSS path
|
v
Go Gateway
These paths cooperate, but they do not need to be implemented by the same process.
Why separate components?
remFREE deliberately uses technologies according to their strengths.
Laravel is strong at:
- application development
- authentication
- database-backed workflows
- routing
- web UI
- business logic
Go is strong at:
- persistent network services
- concurrent connections
- endpoint agents
- long-running processes
- compact binaries
Apache is strong at:
- mature HTTP serving
- TLS-facing web hosting
- virtual hosts
- request routing
MariaDB is strong at:
- relational application data
- transactional persistence
- querying structured operational records
The architecture does not use multiple components just to be complicated.
Each one has a clear job.
Failure isolation
Separating responsibilities also improves troubleshooting.
For example:
If the website is unavailable:
investigate Apache / PHP / Laravel
If the website works but agents are offline:
investigate WSS / gateway / agent connectivity
If agents are online but a job fails:
investigate the job and endpoint execution
If remote control alone fails:
investigate WebRTC / helper / graphical session
This is one of the major benefits of having clear architectural boundaries.
The complete picture
At a high level:
Technician Browser
|
HTTPS
|
v
Apache
|
v
Laravel / PHP
|
MariaDB
|
+--------------------+
|
job / policy logic
|
v
Go Gateway
|
WSS
|
v
remFREE Agent
|
v
Operating System
Remote control adds another real-time media path using WebRTC.
The result is not one giant process. It is a collection of specialized components working together as one management platform.