Two branches can share a billing application hosted at one site when the software supports that arrangement and both locations can reach its approved service. The connection needs explicit access rules, a working reply path and a plan for loss of the shared host or either location’s internet connection.
A recorded Fibmesh deployment used Public IPs with full-tunnel routing on the application host to make shared billing reachable while keeping the server on the business’s premises. That example is useful evidence for an assessment; the application and operating requirements still need checking for each new deployment.
The recorded Public IPs shared-billing deployment
The recorded Fibmesh example concerns a restaurant business with separate billing servers. Billing was consolidated onto one application server at one restaurant. A Fibmesh Public IP made that host reachable from the other location, allowing both to use the same application while the server stayed on the business’s premises.
The application host used Public IPs with full-tunnel routing. The example does not describe a Networks private mesh or routing changes for every device in the restaurants.
See the recorded shared billing deployment →Those are the established facts. The design checks below are lessons for evaluating a similar arrangement. They should not be read as additional reported features or outcomes of that deployment.
Plan for the shared server and connection dependencies
Before consolidation, losing one server may affect one location. With a shared application, the host and its connection become dependencies for the remote location as well.
Put the application host, its local internet connection and the remote location’s connection on a simple sketch. Add the person responsible for each. The drawing should make it obvious which parts must work for a billing operation to complete.
A stable public address gives the remote client a destination. It does not make the host resilient to power loss, keep the application process healthy or provide an alternate internet path. Any requirement for continuity needs its own supported design and operating agreement.
This is a good point to ask the application supplier what happens during a disconnection. Does the application support an offline workflow? How are partially completed operations recovered? Record the actual answers; a network delivery service cannot supply missing application behavior.
Restrict access to the billing application
“Billing server” is a convenient label, but it can hide several services. Find out which one the remote client is supposed to use and what authentication it requires.
Permit the required protocol and port under the assessed deployment. Keep unrelated administration, storage and database listeners outside that exposure unless the application design explicitly requires and protects them. Each user should retain the application permissions appropriate to their work.
A public address is not evidence that the caller belongs to the business. The distinction between network location and authorization is central to NIST’s Zero Trust Architecture. Use address restrictions where they help, while retaining application authentication and authorization.
Check outgoing dependencies under full-tunnel routing
The historical host used full tunnel, so a comparable assessment must consider outgoing internet traffic alongside incoming application access. A billing application may have external dependencies; identify the actual ones rather than assuming the server only receives connections.
For each dependency, record whether it cares about the observed source address, address family or route. Test an ordinary operation through the intended connection. A background job deserves its own test if it uses a different process or remote service.
The request and reply also need a complete path. A server replying through an incompatible route can make an otherwise plausible design fail. WireGuard’s routing discussion provides technical background on how tunnel traffic and route selection interact; it is not a deployment recipe for this historical customer.
Test completed and interrupted billing operations
Agree a test operation with the application owner. Use safe test data and confirm the result in the authoritative application record. A login page loading is only the beginning of that test.
Then consider the uncomfortable case: the connection drops after someone submits an operation but before they see confirmation. Staff need an application-approved way to determine whether it completed before trying again. Otherwise a connectivity incident can become a data-reconciliation problem.
This is not a claim that any particular billing application duplicates transactions. It is a question worth settling before people encounter an ambiguous result during real work.
Document ownership, backups and outage procedures
The handover should identify the server owner, the application support contact and the person who can change the connection. Include maintenance arrangements, the agreed backup and restore process, and the procedure for operating while the shared service is unavailable.
Keep that information accessible without relying on the billing server itself. After a planned restart or a connectivity change, repeat the acceptance operation from the remote location and record what was checked.
A shared billing system can make more than one location work from the same application. The connection succeeds operationally when the people running those locations also know what they depend on, what a failed operation means and who can restore the service.
