# IT-Nerds GmbH — English — full context > Status: working translation; the German source is authoritative. ## [IT-Nerds GmbH](https://it-nerds.eu/en/)IT consulting, planning, and implementation for regulated, public, social, and outage-sensitive organisations. Technology may be complex. Operations should not be. We provide vendor-independent advice, planning, and implementation for robust digital infrastructure in organisations where outages have real consequences. Networks, connections, and interfaces form the foundation. For regulated, public, social, and outage-sensitive organisations. ### Typical situations You do not need to know the technical cause yet. Tell us what is not working in operations, taking too much time, or becoming unnecessarily complex. We first clarify the problem, its context, and the technology already in place. - Disruptions and recovery: When outages recur or the path back to normal operations is unclear. - Unclear connections: When networks, interfaces, or statements from involved service providers do not align. - Accumulated complexity: When changes become hard to assess and operations take unnecessary time. Only then do we recommend a technical measure or procurement—if it is actually needed. ### Services How you can engage us A technical situation assessment, an architecture or network review, project planning, or a defined implementation—supplemented by reviews and support by agreement. - Consulting & project planning: Structure requirements, risks, and decision paths. - Networks, routing & radio: Plan robust site networks, interconnections, and radio links. - Linux, Open Source & Standards: Use open systems deliberately to improve maintainability and independence. ### Experience & fields of work Experience that does not belong on display. We work in regulated, outage-sensitive, and security-critical environments. There, technical decisions must not only work; they must also be verifiable, documented, and sustainable over the long term. Many of our projects are subject to confidentiality. That is why we discuss tasks, approaches, and results—not customer names. - Regulated organisations: Experience in healthcare and finance as well as public and social institutions. - Critical operating environments: Work in outage-sensitive and security-critical contexts, including defence-related and classified-information environments. - Site networks & microwave links: Practical experience with distributed site interconnections, routing transitions, radio links, and microwave connections. - Open network platforms: OpenWrt, VyOS, OpenBSD, and OPNsense for transparent, maintainable infrastructure. ### Approach Understand first. Then build. Five steps from reviewing what exists to a documented handover. - Map the information chain: Make relationships visible. - Clarify the function: Who needs what, and what happens when it fails? - Review what exists: Not everything needs replacing. - Order dependencies: Use open standards where they help. - Hand over operations: Document decisions and transfer knowledge. ### Make technology understandable Principles, methods, and common questions—explained clearly, without vendor brochure language. ### Mindset / IT nerd Do not stop at the first plausible answer. Why scepticism, persistence, curiosity, and technical integrity make a difference in complex projects. ### Contact No form, no funnel—an email or a call is enough. Briefly describe your situation; we will clarify the technical fit and whether and how we can support you. - E-Mail: info@it-nerds.eu - Phone: +49 30 319 55 979 - Location: Haynauer Straße 40, 12249 Berlin ## [Company](https://it-nerds.eu/en/company/)Responsibility, discretion, and contact details at IT-Nerds GmbH. IT-Nerds GmbH advises organisations whose operations require dependable technology and responsible handling of sensitive information. Responsible contact Martin Koltonowski is the managing director, founder, and technical point of contact at IT-Nerds GmbH. He has around 20 years of experience in IT, infrastructure, networks, and technical environments. His areas of expertise are IT infrastructure; networks, routing, and wireless technology; Linux and open source; technical analysis; operational resilience and recovery; and robust, understandable system architectures. IT-Nerds GmbH grew out of a desire to approach IT with greater independence, honesty, and technical rigour. Its aim is to help companies not only use their infrastructure, but understand and control it and keep it manageable in an emergency. Operating model IT-Nerds is an owner-managed specialist consultancy focused on the technical analysis, planning, and implementation of robust IT and network infrastructure. Responsibility We align technical decisions with the task. We involve the people who operate or take over systems so that responsibilities and knowledge do not remain solely with external parties. Discretion Many fields in which we work are regulated, outage-sensitive, or security-critical. We therefore publish no customer, personal, or project data and discuss tasks, methods, and results only in abstracted form. Anonymised project profiles The anonymised project profiles show examples of our work without naming clients or disclosing confidential operational details. Contact Approved contact details are available on the homepage. The legally authoritative German documents are linked under Legal notice and Privacy. ## [Knowledge](https://it-nerds.eu/en/knowledge/)Technical reasoning and practical methods for architecture, operations, and handover. This section separates why from how: the principles explain architecture decisions, while the approach shows the process. Both provide guidance without replacing an analysis of the specific project. ## [Approach](https://it-nerds.eu/en/knowledge/approach/)Five steps from the initial assessment to operational handover. Map the information chain We map applications, processes, interfaces, networks, and communication paths. The result is a shared view of the relevant information chain. Clarify the function We clarify who needs which function, the consequences of failure, and the required response times. This establishes the measure for further planning. Review what exists We assess existing technology and known constraints against this measure. What is suitable stays; replacement requires a reason. Order dependencies We identify technical and organisational dependencies, responsibilities, and the effects of changes. We use open standards when they reduce a specific dependency or ease a transition. Hand over operations We record decisions and responsibilities, review the documentation together, and transfer the knowledge needed for operation, change, and recovery. ## [The IT nerd as a mindset](https://it-nerds.eu/en/knowledge/it-nerd/)Why scepticism, persistence, curiosity, and technical integrity matter in complex IT projects. The name IT-NERDS expresses our commitment to approach IT independently, honestly, and with technical rigour. It means curiosity and technical depth, independent judgement, and taking responsibility for explaining decisions clearly and documenting them so they can be reviewed. This helps organisations not merely use their infrastructure but understand and control it, and keep it manageable in an emergency. Whether we live up to that commitment is demonstrated by our work, not by the name itself. The following classification is deliberately humorous and makes no scientific claim. People are, of course, more than labels or circles in a diagram. Not particularly scientific, but surprisingly recognisable in everyday life. From label to mindset When intelligence and enthusiasm meet, the diagram calls the result a geek: someone who voluntarily explores a subject more deeply than may seem strictly necessary. When enthusiasm and social independence meet, the tongue-in-cheek label is dork: deeply absorbed in a subject while occasionally treating convention as optional guidance. The combination of intelligence and social independence becomes the dweeb: clever, analytical, and perhaps more persuasive when talking to a server than while making small talk. At the intersection is the nerd: intelligent enough to understand a complex problem, persistent enough not to abandon it too early, and independent enough not to be overly impressed by fashions or group dynamics. These English labels are imprecise and do not translate neatly. The label matters less than the mindset behind it. What distinguishes an IT nerd? An IT nerd combines expertise, scepticism, persistence, and a necessary sense of humour. Instead of following every trend, the focus remains on solutions that are robust, understandable, and controllable. For us, digital independence therefore means more than cloud, compliance, or large claims about resilience and sovereignty. It begins with a simpler question: Does an organisation still understand and control its own infrastructure? If the answer is unclear, the problem is often not purely technical. Difficulties commonly arise around organisation, responsibilities, communication, fear of mistakes, entrenched habits, budget logic, or an inability to make decisions. IT people sometimes jokingly call the human being at the keyboard Layer 8. No such layer exists in the official network models. In practice, however, human and organisational factors often determine whether technology supports work or merely creates more complexity. This is not about blame; it is a reminder to consider systems together with their users and owners. Between a technical problem and a durable solution often lie hype, politics, time pressure, and human uncertainty. Why is this mindset a good partner? The IT nerd is not an isolated eccentric who communicates only with blinking machines in a dark basement. In complex situations, one ability is particularly valuable: They tolerate not knowing for a little longer. They do not immediately lose patience when something fails. They do not replace a product merely because a process has stalled. And they do not confuse a new interface with a solved root cause. Instead, they ask: What is actually happening? Which dependencies exist? Which assumptions have not yet been tested? Is the system understood in its constituent parts? Are we solving the problem, or only its visible symptom? They aim not to become emotionally attached to a vendor, product, or their own initial opinion. A preferred solution may be discarded when evidence contradicts it. A cherished concept may fail. Even one’s own mistake is acceptable, provided one is willing to find and correct it. That is not stubbornness. It is technical integrity. Perhaps every organisation needs an IT nerd Someone who wants to understand relationships, systems, and processes. Someone who does not stop at the first plausible result, but follows a cause carefully. Someone who does not reinterpret technical facts for convenience, hierarchy, or political expediency. Budgets, priorities, and strategies can be negotiated. Physics is less accommodating. For a consultancy, this mindset is credible only when paired with communication, documentation, and respect. That is why it belongs in this knowledge section: not as self-congratulation, but as a standard against which our work can be judged. ## [Principles for controllable systems](https://it-nerds.eu/en/knowledge/principles/)How openness, repairability, documentation, and clear dependencies support robust IT. Robust IT is not the IT with the most products. It is the IT whose purpose, dependencies, and recovery paths are understood. Technology may be demanding, but its operation should not depend on chance, individual memory, or opaque interfaces. Begin with the function Before selecting components, clarify which function must be preserved. Who needs which information? What response time is required? What may fail temporarily, and what may not? These questions provide a durable frame for architecture decisions. Consider the information chain Applications rarely stand alone. Devices, identities, networks, name resolution, time sources, storage, backups, and communication paths form a chain. A problem in an inconspicuous link can stop a visible business function. Use openness for a purpose Open source and open standards are tools, not decoration. They are valuable when they improve replaceability, auditability, maintainability, or knowledge transfer. An open component without responsibility and operational knowledge does not solve a problem. Vendor independence does not mean avoiding every vendor. It means aligning decisions with the task and making avoidable dependencies visible. Plan for repairability Repairability begins before a defect. Alternative paths, configuration backups, traceable changes, and accessible documentation must exist before an incident. A system is not robust when recovery exists only in one person’s memory. Keep dependencies visible Every dependency may be justified. It becomes a problem when it is unknown, unnecessary, or beyond influence. This includes technical dependencies as well as contracts, accounts, key individuals, and external services. A useful overview answers at least: Which function depends on it? Who is responsible? How is the dependency monitored? Which alternative or emergency mode exists? How can the state be restored? Treat documentation as an operational tool Documentation is not a project completion photograph. It is an operational tool and should answer the questions that arise during changes, handovers, and incidents. Decisions deserve as much attention as configurations. Make knowledge transferable A controllable system must not permanently depend on individual knowledge. Handover sessions, shared walkthroughs, and clear terminology make knowledge resilient. Think about security and privacy together Security does not emerge from a single control. Identities, permissions, network boundaries, updates, backups, logging, and recovery work together. Privacy additionally requires an understanding of data flows, purposes, and external recipients. Prefer less, consciously Each additional component increases operational, update, and documentation work. The simplest viable solution is often the most robust: clear enough to operate, open enough to change, and complete enough to recover. ## [Legal notice](https://it-nerds.eu/en/legal-notice/)Reference to the legally authoritative German legal notice of IT-Nerds GmbH. This English page is only a navigation aid and is not a legal translation. Please read the legally authoritative German Impressum. It contains the approved company and contact information from the existing IT-Nerds source. ## [Privacy](https://it-nerds.eu/en/privacy/)Information about the processing of personal data when visiting the website and contacting IT-Nerds GmbH. Status date: 27 August 2026 This privacy notice explains which personal data IT-NERDS processes when you visit the website or contact us, the purposes and legal bases of the processing, and the rights available to data subjects. Controller and contact details IT-Nerds GmbH Haynauer Straße 40 12249 Berlin Deutschland IT-NERDS GmbH is the controller responsible for the processing described below. Privacy questions can be sent to us using the email address provided. Represented by the management Email: info@it-nerds.eu Telephone: +49 30 319 55 979 Website access and Cloudflare Pages This static website is delivered through Cloudflare Pages. Cloudflare processes technically necessary connection and delivery data, in particular the IP address, time and requested resource, and transmitted browser, system and referrer information. The data subjects are visitors to the website; the data arise when a page is accessed and are transmitted to Cloudflare for technical delivery. The purpose is the secure and stable provision of the website. The legal basis is Article 6(1)(f) GDPR; our legitimate interest is reliable delivery protected against attacks. Cloudflare is involved in the processing as a service provider and receives the data necessary for delivery. As part of its global operations, Cloudflare may also process data in third countries. For such transfers, the Cloudflare Customer Data Processing Addendum provides, among other safeguards, the EU Standard Contractual Clauses. The EU Standard Contractual Clauses form part of the Cloudflare Data Processing Addendum and are publicly available there. Retention is determined by what is necessary to provide the service and by applicable contractual and legal obligations. Contact by email When you contact us by email, we process in particular your contact details, the content of your message and the metadata needed for communication, such as sender and recipient addresses, time and subject. The purpose is to identify, handle and answer your enquiry. The legal basis is Article 6(1)(b) GDPR where the communication concerns a contract or pre-contractual steps. For other business enquiries, the legal basis is Article 6(1)(f) GDPR; our legitimate interest is to handle and answer those enquiries. We use Zoho Mail in the European service domain zoho.eu for email communication. Zoho is involved in the processing as a service provider, and a data processing agreement is in place. According to Zoho, data in this service domain is generally stored and processed within the EU. Limited access from India may occur in certain cases for support purposes. Zoho relies on EU Standard Contractual Clauses for such access and describes supplementary access-control and security measures in its privacy information. Contact by telephone We use O2, a service provided by Telefónica Germany GmbH & Co. OHG, for telephone services. In the local call list on one telephone, IT-NERDS processes in particular the telephone number, time and direction of the call to identify and handle incoming and outgoing business calls. Depending on the reason for the call, the legal basis is Article 6(1)(b) or (f) GDPR. Entries are deleted 90 days after the call date. Calls are not recorded. Retention and deletion We generally delete general and unsuccessful enquiries 12 months after the last substantive communication. For a specific unsuccessful project initiation, retention may exceptionally last up to 24 months if the continuing business need is documented. During an ongoing enquiry or quotation phase, we process the data until it is concluded. We then classify it according to the criteria described here or delete it. Emails that constitute commercial or business correspondence or other records subject to a statutory retention requirement are stored for the applicable statutory period; the legal basis in this respect is Article 6(1)(c) GDPR. We retain data relating to contracts or disputes only for as long as necessary to perform the contract, establish, exercise or defend legal claims, or comply with statutory obligations. Where retention serves to establish, exercise or defend legal claims, the legal basis is Article 6(1)(f) GDPR; our legitimate interest is to safeguard and enforce our legal position. We then delete the data under our control. Appearance and local search The website stores the value light or dark under the local storage key it-nerds-theme only after an active choice. Selecting system removes the key and uses the system setting again. The storage is necessary to provide the expressly requested appearance on subsequent page visits; the basis is section 25(2) no. 2 TDDDG. No theme value is stored without an active choice. The local site search loads a static search index from this website. Search terms are processed in the browser and are not transmitted to third parties. The website does not use analytics, tracking or advertising services and does not embed external content. Rights of data subjects Under the GDPR, data subjects may in particular request access, rectification, erasure, restriction of processing and data portability. Where processing is based on Article 6(1)(f) GDPR, there is a right to object under the statutory conditions. Requests to exercise these rights can be sent to info@it-nerds.eu. You also have the right to lodge a complaint with a data protection supervisory authority. The supervisory authority responsible for IT-NERDS GmbH is the Berlin Commissioner for Data Protection and Freedom of Information. Voluntary contact Contacting us is voluntary. Without the information required to process an enquiry, the enquiry may not be processed. ## [Anonymised project profiles](https://it-nerds.eu/en/project-profiles/)Abstracted accounts of tasks, approaches, and deliverables from confidential project environments. Many of our projects are confidential. These profiles therefore contain no client names, personal details, locations, or identifying operational information. Instead, they explain the situation addressed, our role, and the deliverables handed over. Each page is marked anonymised project profile · client confidential. It is not a client endorsement and contains no invented metrics. ## [More resilient network connectivity in a hospital environment](https://it-nerds.eu/en/project-profiles/resilient-network-connectivity-healthcare/)An anonymised project profile covering the use of multiple existing paths with Multipath TCP (MPTCP) and an operational handover. Anonymised project profile · client confidential Context The project took place in a hospital environment with demanding requirements for stable network connectivity, understandable operational processes and dependable communication. The client, location, providers and specific architecture remain confidential. Initial situation and objective Brief connection interruptions repeatedly occurred during daily operations. Individually, they were difficult to isolate; together, they affected applications, workflows and users’ experience. The aim was to reduce dependence on individual links and providers while making better use of the existing infrastructure. Within the defined project scope, this required neither new hardware nor additional licensing models. Role and approach IT-NERDS assessed the existing environment, analysed recurring interruption patterns and reviewed the network and operational structure. Existing connections and Linux-based systems were then combined using high-availability mechanisms and Multipath TCP (MPTCP), so that a brief disruption on one path had less immediate impact on users. A separate, clearly segmented network for staff members’ personal devices was included without unnecessarily opening internal systems. The operations team received a briefing on how the solution works, its operational logic and basic fault analysis. Technologies Linux-based systems Multipath TCP (MPTCP) high-availability mechanisms network segmentation existing network components and connections open standards Outcome and deliverables The existing paths could be used more resiliently, reducing dependence on any single path. Deliverables included a technical assessment, reproducible configuration, operational documentation, recommendations for continued operation and the team briefing. No availability figures or formal assurance are claimed in this profile. ## [Authorised security review and segmented protection architecture in professional services](https://it-nerds.eu/en/project-profiles/security-review-professional-services/)An anonymised project profile covering an independent technical review and a complementary BSD-based protection architecture. Anonymised project profile · client confidential Context The project concerned a tax advisory and accountancy environment with demanding requirements for confidentiality, secure data flows, remote work and understandable security measures. The client, people, location, products and specific weaknesses remain confidential. Initial situation and objective A previous service provider had implemented infrastructure hardening and remote-work measures. An independent review was then required to determine whether the actual implementation met the defined requirements and which technically relevant risks remained. The objective was an objective validation of the current state. The previous service provider was neither publicly rated nor made identifiable. Review, advice and implementation IT-NERDS carried out an authorised technical review from attacker and operator perspectives. Existing security measures, remote-work capabilities, network segmentation and relevant access and data-flow paths were examined. The findings were documented with prioritised recommendations. Separately, IT-NERDS advised on and implemented a complementary protection architecture. A DMZ-like BSD-based structure allowed sensitive data flows to be separated and directed more transparently. The specific configuration and identified weaknesses are not published. Technologies and principles network segmentation and DMZ-like architecture BSD-based security systems controlled access separation and data-flow handling technical hardening open protocols documented operational handover Outcome and deliverables Deliverables included technical findings, prioritised recommendations, the complementary protection architecture and reproducible operational documentation. The BSD-based solution was selected as a technically suitable and inspectable option for this task, not as a blanket judgement against proprietary products. The profile makes no claim of formal attestation, compliance, successful defence or quantified risk reduction. ## [Segmented decentralised connectivity in a care facility](https://it-nerds.eu/en/project-profiles/segmented-connectivity-care-facility/)An anonymised project profile covering separated network access for residents, visitors, staff and operational services. Anonymised project profile · client confidential Context A larger care facility needed straightforward, stable and clearly separated connectivity for residents, visitors, staff and selected operational services. The location, operator and specific building information remain confidential. Initial situation and objective Separate connections for individual residents would have required recurring technician visits, individual provisioning, some building work and considerable administration. New residents, guests and personal devices needed access without complex per-device approvals, while operational systems had to remain separate. The objective was a maintainable solution without a separate connection for each resident and without unnecessarily opening the internal infrastructure. Role and approach IT-NERDS assessed the building and network situation, reviewed available connection options and designed a decentralised architecture. A Freifunk-inspired approach provided logically separated access areas. Multiple gateways or connection points distributed the available connectivity to the intended user groups. Private and operational use were separated through segmentation, clear network boundaries and Zero Trust principles. Here, “Zero Trust” describes a design principle rather than a complete formal implementation. Technologies and principles decentralised network architecture Freifunk-inspired approach multiple gateways and connection points logical network segmentation Zero Trust principles open protocols and maintainable components Outcome and deliverables Residents, visitors and staff gained more flexible access while operational systems remained separate. Administrative effort for individual connections and device approvals was reduced without claiming quantified savings. Deliverables included the technical design, network and segmentation logic, operational documentation and guidance for fault handling. The profile makes no formal classification of the facility or solution. ## [Services](https://it-nerds.eu/en/services/)Consulting, planning, and implementation for networks, open platforms, and managed IT infrastructure. Our services range from technical assessment and project planning to implementation and agreed ongoing support. Scope and outcomes depend on the task, the operating environment, and the technology already in place. Consulting and project planning We prepare decision material and project plans for applications, processes, networks, and communication paths. This includes requirements, risks, priorities, and the next actionable steps. Networks, routing, and radio We plan and implement local networks, site connections, routing, radio networks, and microwave links. Linux, open source, and standards We plan router and firewall solutions with OpenWrt, VyOS, OpenBSD, and OPNsense, as well as other suitable open standards. The task and long-term operability determine the choice. Operations, maintenance, and knowledge transfer By agreement, we provide support, maintenance, and managed installations. Our services also include assessing and planning decentralised cloud infrastructure; every handover covers documentation, clear responsibilities, and the operational knowledge required. ## [Consulting & project planning](https://it-nerds.eu/en/services/consulting-project-planning/)Clarify the technical starting point, prepare architecture decisions, and plan actionable project or migration paths. Consulting and planning are the usual starting point when critical functions depend on infrastructure that has grown over time, is only partly documented, or needs to change. We primarily work with regulated, public-sector, social-service, and outage-sensitive organisations. We consider demanding private-client projects individually. Typical starting situations Important applications, networks, interfaces, or responsibilities are only partly documented. Incidents cannot easily be traced to a technical or organisational dependency. Sites, network segments, routing, or radio links have evolved over time and changes are difficult to assess. The intended change is known, but its sequence, responsibilities, transitions, and fallback paths remain open. A shared, traceable basis for decisions is missing before an investment, migration, or implementation. Objective and scope We clarify the relevant information chain, the function it needs to provide, known constraints, and responsibilities. Depending on the question, the agreed scope may include one or more of these starting points: Technical situation assessment We map relevant applications, processes, interfaces, networks, and communication paths. Existing documents and technology are included; dependencies, responsibilities, and open questions are structured. Architecture and network review We assess an existing or planned architecture against function, dependencies, operability, and recoverability. This may cover local networks, site connections, routing, radio networks, and microwave links. Recommendations are based on technical reasoning and are not tied to product or licence sales. Project and migration planning We record the objective, requirements, constraints, and exclusions, then structure work packages, dependencies, decision points, and responsibilities. Transitions, fallback paths, and the eventual operational handover are considered from the outset. Approach and possible artefacts At the outset, we jointly define the question, affected functions, and available information. We then map and review the agreed environment, organise findings and dependencies, and prepare the decisions ahead. Depending on the engagement, possible artefacts include: a structured technical situation assessment; an overview of relevant information chains, interfaces, and dependencies; a review report with findings and reasoned recommendations; an updated architecture or network diagram; a project or migration plan with work packages and responsibilities; a list of open questions, risks, decision options, and next steps; an approach to handover, fallback, and recovery. These are possible working artefacts, not generally promised outcomes. The specific engagement determines which documents are needed and how detailed they will be. Roles and client contribution We provide the moderating and technical review role and the agreed planning. A reliable basis requires both decision-makers and people on the client team who understand the applications, operations, and existing technology. The client team provides available documents, system information, and access, identifies internal and external interfaces, and explains operational priorities, approval paths, and constraints. Review times, operating windows, and the involvement of other service providers are coordinated jointly. From planning to implementation and operations Consulting and planning provide a basis for a decision or implementation. Agreed technical work packages can then be implemented by one team, but remain a separate, explicitly agreed scope. After implementation, a defined area can be reviewed to determine whether documentation, responsibilities, access, backups, and recovery paths are usable for operations and handover. Support and maintenance are only available under a separate agreement and do not create general operational responsibility. Boundaries and exclusions no free consulting, fixed prices, or guarantees concerning deadlines, availability, or outcomes; no general response times, SLAs, or blanket 24/7 operations; no penetration test, certification, or standardised compliance audit; no product or licence sales and no conventional reseller model; no general PC, printer, or small-ticket support; no automatic implementation of identified measures without a separate engagement. The service overview places consulting and planning within the overall offer. Read more about the technical principles in Principles for controllable systems and our approach. Anonymised project profiles show bounded examples without naming clients or confidential operational details. Discuss your project Describe the starting situation, affected functions, available documents, and the decision ahead. We can then determine together which starting point and scope fit the project. Discuss your project ## [Linux, open source & standards](https://it-nerds.eu/en/services/linux-open-source-standards/)Assess, plan, and implement clearly bounded open systems and standards based on maintainability, control, interoperability, and long-term operability. Linux, open source, and open standards are not ends in themselves. They are useful when they make a specific task more maintainable, controllable, and interoperable with other systems. The deciding factors are the requirements, the existing environment, and who can operate and recover a solution over the long term—not a blanket promise that open technology is always better, safer, or cheaper. Typical starting situations A Linux or BSD system performs an important function but is only partly documented or depends on individual knowledge. Proprietary and open components need to work together reliably while interfaces or responsibilities remain unclear. A platform needs renewal without unnecessarily replacing existing technology that still serves its purpose. Open formats, protocols, or interfaces should make handover and data exchange easier. A planned change lacks decision criteria, a phased transition, or a reliable fallback path. Backups exist, but restart procedures, access, and responsibilities have not been reviewed together for the affected scope. Decision criteria instead of a matter of principle We assess possible components against the function actually required. Criteria include maintainability, traceable configuration, available interfaces, interoperability, operational knowledge, update paths, dependencies, and the intended service life. Existing licences, contracts, and external services may also affect the decision. Open source code alone creates neither secure operations nor independence. An open solution can be unsuitable if required functions, responsible people, maintenance paths, or usable documentation are missing. Conversely, a controlled combination of open and proprietary systems may be the most robust solution. Analysis, planning, and clearly bounded implementation Analysis We map the agreed function, affected Linux or BSD systems, applications, networks, data flows, and interfaces. Existing documentation, configurations, backups, and responsibilities are assessed within the approved scope. The result is a traceable baseline with assumptions, dependencies, and open decisions—not a blanket product verdict. Planning We develop a target structure and determine which existing components can remain, which transitions are needed, and how operations and fallback should be protected during a change. Work packages, test conditions, responsibilities, and handovers are bounded before implementation. Coexistence or a phased transition is possible when it fits the task and operating environment. Clearly bounded implementation We carry out agreed installation, configuration, integration, and documentation work within the approved scope. Changes to networks, applications, or external services are coordinated with their respective owners. Overall operations, procurement, third-party trades, or unapproved systems do not silently become part of the engagement. Systems and standards in context Linux and BSD systems can serve as platforms, network components, or operations-related infrastructure. OpenWrt, VyOS, OpenBSD, and OPNsense are existing examples of open router and firewall platforms. Suitability depends on function, interfaces, maintainability, and operational handover. The examples are neither complete nor exclusive and do not imply vendor, partner, or certification status. Open formats, protocols, and documented interfaces can make exchange between components and a later handover easier. Whether they are sufficient in a specific environment still requires technical assessment; naming a standard does not replace integration or recovery testing. Operations, backup, fallback, and recovery The agreed operational picture covers more than running systems. We also consider required access, configuration and data backups, dependencies on networks and external services, and responsibilities for changes and incidents. Fallback and recovery paths are planned or reviewed to the level allowed by the scope, available facilities, and approved operating windows. Documentation and backups are important prerequisites, but they are not guarantees of availability or recovery. Practical checks or exercises are only carried out when their scope, risks, and approvals are expressly agreed. Possible documentation and handover artefacts Depending on the engagement, these may include: a current-state overview of affected systems, functions, interfaces, and responsibilities; a reasoned options or decision overview; target and transition planning with bounded work packages; configuration, change, and test records; an overview of access, backups, fallback, and recovery; operational and handover documentation for the agreed scope. These are possible, engagement-dependent working artefacts rather than universally promised outcomes. Content, level of detail, acceptance, and maintenance responsibility are defined for the specific project. Client interfaces and participation The client team names business and technical owners, provides existing material and agreed access, and describes affected functions and acceptable operational risks. Approvals, maintenance windows, acceptance, and involvement of internal teams or other service providers remain clearly assigned. For interfaces and phased transitions, the owners of participating systems need to be available. Missing prerequisites, rights, or decisions are recorded as open client interfaces; they do not create automatic responsibility for systems outside the agreed scope. Boundaries and exclusions no blanket claim that open source is safer, cheaper, or inherently superior; support and maintenance only under a separate agreement; no blanket 24/7 operations; no product or licence sales and no reseller model; no general PC, printer, or small-ticket support; no automatically included migration, certification, compliance assessment, or security guarantee; no guarantees concerning deadlines, availability, savings, or outcomes; no implementation outside the agreed scope or without the necessary approvals. The service overview places this topic within the overall offer. Consulting and project planning establish the decision basis; networks, routing, and radio covers network-specific work in depth. Our principles for controllable systems explain the technical guidelines. Discuss a project involving open systems Describe the affected function, the existing environment, known interfaces, and the intended change. We can then determine which analysis, planning, or bounded implementation is appropriate and which prerequisites need to be addressed first. Discuss your open-systems project ## [Networks, routing & radio](https://it-nerds.eu/en/services/networks-routing-radio/)Analyse, plan, and implement clearly bounded site networks, interconnections, routing transitions, radio networks, and microwave links. Networks connect applications, sites, and people. When their dependencies are unclear or changes are made without a reliable fallback path, even a single transition can affect important functions. We primarily work with regulated, public-sector, social-service, and outage-sensitive organisations. We consider demanding private-client projects individually. Typical starting situations and risks Site networks and interconnections have evolved over time or are only partly documented. Network segments serve different purposes, but their transitions and responsibilities are not clearly bounded. Static or dynamic routing decisions are difficult to trace, or changes can only be prepared with a high operational risk. Radio networks or microwave links need to be added, renewed, or integrated into an existing network. Dependencies on power, mounting locations, existing cabling, or external connections remain open before implementation. Fallback and recovery paths are not sufficiently documented or practically verifiable. Analysis, planning, and implementation The specific engagement is bounded by the affected functions, sites, and interfaces. Analysis, planning, and implementation can build on one another, but remain traceable work packages with their own prerequisites and approvals. Analysis We map the agreed environment, relevant network segments, interconnections, routing transitions, and radio links. We organise dependencies, known constraints, responsibilities, and available documentation. For radio and microwave projects, the agreed assessment may also consider site conditions, mounting paths, and integration with the wider network. Planning We develop an implementable target structure and describe the required transitions. This may include segmentation boundaries, routing behaviour, radio links, the sequence of changes, test conditions, and fallback and recovery paths. Decisions and open assumptions are documented so they can be reviewed before implementation. Clearly bounded implementation We carry out agreed configuration, integration, and commissioning work within the approved scope. Work on buildings, power, cabling, or external connections is only included when expressly agreed and covered by the necessary expertise. Changes take place in coordinated windows with the test and fallback points defined for the project. Open router and firewall platforms in context Depending on the task, OpenWrt, VyOS, OpenBSD, and OPNsense can be suitable examples of open router or firewall platforms. Requirements, existing interfaces, necessary functions, maintainability, and the intended operational handover determine the choice. These systems are neither a complete nor an exclusive technology list and imply no vendor or partner relationship. Operational resilience, fallback, and recovery Operational resilience is considered throughout the engagement: from traceable dependencies and coordinated changes to usable backups, fallback paths, and an orderly handover. Which tests or recovery exercises are useful and feasible depends on the agreed scope and operating environment. Redundancy or alternative connection paths may form part of a plan. This does not provide a blanket guarantee of high availability, compliance, certification, availability, or outcomes. Possible documentation and handover artefacts Depending on the engagement, possible artefacts include: an as-is or target overview of relevant networks, segments, and interconnections; a traceable description of routing transitions and dependencies; route or mounting plans for agreed radio and microwave links; configuration, change, and test records; an overview of responsibilities, interfaces, and open points; a handover package covering backup, fallback, and recovery paths. These are possible, engagement-dependent working artefacts, not generally promised outcomes. Their content, level of detail, and maintenance responsibility are defined for the specific project. Client interfaces and contribution The client team identifies the business and technical contacts, affected functions, operational priorities, and authorised approvers. It provides available documents and agreed access, coordinates change windows, and involves internal operations staff and external parties where needed. For radio and microwave projects, site access, mounting approvals, power and cable paths, and any required coordination with property owners or other responsible parties must be clarified. Missing prerequisites and decisions are recorded as open client interfaces; they are not silently assumed to be part of the technical implementation. Boundaries and exclusions support and maintenance only under a separate agreement; no blanket 24/7 operations; no guarantees concerning high availability, deadlines, availability, or outcomes; no product or licence sales and no reseller model; no general PC, printer, or small-ticket support; no automatically included penetration test, certification, or compliance audit; no implementation outside the agreed scope or without the necessary approvals. The service overview places network work within the overall offer. The approved anonymised project profiles on more resilient network connectivity in a healthcare environment and decentralised connectivity for a care facility provide bounded practical examples without naming clients or disclosing confidential operational details. Discuss your network project Describe the affected functions and sites, the known environment, the intended change, and available operating windows. We can then determine which analysis, planning, or bounded implementation is appropriate and which prerequisites need to be addressed first. Discuss your network project