Where should production records live? The infab.cloud deployment choice

People often discuss a production system in terms of what it can display. Can the planner find an order? Can an operator see the next job? Can quality attach evidence to an inspection? There is another question worth asking before any of those screens become part of daily work: where will the records actually live? A technical drawing, a time entry and the lot used on a job all have an address somewhere. Choosing that address affects not just IT procurement but the network the workshop relies on and the people who will look after it.

infab.cloud is designed to run on a server at the customer’s site or on a server the customer rents. It sits alongside an existing ERP rather than replacing that system. Those two decisions belong in the same conversation. Running a production application on your own infrastructure does not mean moving accounting into it. Nor does keeping a server close to the workshop automatically connect it to every other record system. The deployment boundary and the business process boundary need separate decisions.

Start with the data, not a server quotation

Imagine a made up order in a metal workshop. Someone prepares a recipe and opens work orders; later, the team records a material lot and attaches a photograph during inspection. This is an illustration based on record types described in the product documentation, not a customer case. Before selecting hardware, ask which of those records may leave the facility network and who needs to read them. A planner’s need to see progress is different from a contractor’s right to receive a technical drawing.

A server that the company rents is under the company’s chosen operating arrangement, but it is not physically inside the factory. A server kept on site can sit behind a different network boundary. The product supports both deployment choices; describing them as identical because both are “self hosted” would hide a significant distinction. If a contract says production data cannot leave the premises, a rented machine elsewhere cannot satisfy that requirement simply by belonging to the same company. Write down the location requirement before comparing features.

The documentation also describes operation in a network with no internet connection. That is an option to design for, not a property that applies automatically to every installation. Optional AI features illustrate why the detail matters. An external model provider requires connectivity, while a local model can be used without sending that workload over the internet; the feature can also be disabled. When reviewing data boundaries, decide which option is in scope. A general claim that every deployment sends no data outside would be too broad for a product with optional external connections.

What does a single server actually contain?

The current technical installation uses Docker Compose on one server. The documented components include a web frontend, application backend, database, authentication service and file storage. Keeping these services together provides a concrete way to discuss where operational records and attached files reside. It also avoids making a separately hosted database or file service a prerequisite for this installation. None of that removes the need to administer the services running on the machine.

The moment a workshop depends on those records, someone owns backups, updates, access and fault response. The product documentation is candid that a self hosted model asks for more hands on installation and support than a centrally operated service. “Our server” is not a complete operating plan. Who can restore the database? Who monitors available storage? Who coordinates an update with a production shift? These are questions for an actual pilot, not details that can safely be inferred from the phrase “one server.” A system can have a straightforward architecture and still require careful operation.

It also matters what is available now. Current documentation describes Docker Compose for pilot and early customer installations. One click installers and a licensing or activation workflow are listed as future distribution work. If a team evaluates the product today, it should plan for technical involvement rather than assume a packaged installer already exists. The point of describing the present deployment honestly is not to make it sound difficult. It is to make the boundary between software capability and installation work visible before the first production record is entered.

An existing ERP changes the access question

A factory may already have its accounting, purchasing or stock records in an ERP. infab.cloud’s role is to record the work of planning and production beside that system. “Beside” should not be read as a promise of an automatic connection to whatever ERP happens to be installed. The current documentation describes an available Odoo connection whose synchronization is started manually. Connections to other named ERP products are not presented as ready to use. An integration plan therefore begins with a specific data question: which record has authority, and through which network path would it be reached?

For a site without internet access, draw that path on paper before assuming the installation is independent of every other service. If an optional ERP connection is needed, is the other system reachable inside the permitted network? If it is not, which information will staff enter in the production application? Installation guidance asks teams to prepare network access decisions alongside users, roles, machines and operations. A working server does not invent those definitions. The people who know the production route and the people responsible for the network need to agree on them.

A modest evaluation can use one type of order rather than trying to model the whole factory. List the drawing, recipe, material and quality records it would create. For each one, mark its intended storage location and the person who maintains that location. Then walk from opening the order to viewing an attachment on the chosen network. If the company is comparing a facility server with a rented one, perform the same exercise for both. This is a test of your operating assumptions, not a claim that one placement is best for every workshop.

Local control is useful when it answers a specific question about where production information is allowed to reside. It comes with equally specific responsibilities for the machine and its services. The infab.cloud product site and deployment documentation provide the product context; the decision for your own site starts with a simpler question: which records must stay within which network boundary?

Verification note: Deployment choices, present components and planned distribution work were checked against the Turkish infab.cloud documentation, the product repository’s architectural decision and the current product website. The workshop scenario is illustrative, not customer data.