CFTS Documentation

Software and DevOps

CFTS develops and maintains selected software, automation, and operational tools where doing so provides a practical advantage in control, integration, supportability, or service delivery.

This work is not based on a preference to build everything ourselves. Where an established product already solves a requirement well, CFTS will normally use it. Where a requirement falls between products, creates unnecessary dependencies, or needs closer integration with the infrastructure we operate, we may develop the missing capability in-house.

The result is a combination of established platforms, CFTS-developed services, APIs, automation, and operational tooling working together as part of the wider CFTS service stack.

What DevOps Means at CFTS

For CFTS, DevOps is primarily a practical engineering approach rather than a product or department.

It brings software development and infrastructure operations together so that tools can be designed around the environment in which they are actually used.

Typical areas include:

  • internet and uplink monitoring
  • connectivity and failover assistance
  • service and infrastructure diagnostics
  • virtual machine and service control
  • controlled file and document delivery
  • communications and support workflow integration
  • DNS and network automation
  • deployment and maintenance tooling
  • internal APIs and service integration
  • documentation and operational knowledge systems
  • AI-assisted operational tools where appropriate

Some of these capabilities are visible directly to clients. Others operate behind the service and help CFTS engineers monitor, support, recover, or manage infrastructure more effectively.

Why We Develop Selected Tools In-House

Commercial products are often the correct answer, particularly where a mature and well-supported platform already exists.

However, a general-purpose product may also introduce complexity, licensing overhead, weak integration, unnecessary external dependencies, or functions that do not match the operational requirement closely enough.

In those cases, a smaller purpose-built tool can sometimes be easier to understand, secure, maintain, and recover.

CFTS therefore considers both options:

  • use an established platform where it fits the requirement well
  • integrate existing systems where this provides the required result
  • develop a focused capability where there is a genuine operational gap

The objective is not custom software for its own sake. The objective is a supportable solution to a real operational problem.

Client-Facing and Operational Systems

CFTS-developed capabilities generally fall into two broad groups.

Client-Facing Platforms

These provide a direct service or controlled access point for clients. Examples include service portals, file delivery, infrastructure visibility, and other tools designed to simplify interaction with CFTS-operated services.

Operational Tooling

These systems work mainly behind the service. They may assist with monitoring, diagnostics, deployment, DNS, failover, automation, documentation, infrastructure control, or engineering workflows.

This distinction is deliberate. Not every internal tool needs to become a client product, and not every client-facing service needs to expose the complexity behind it.

Relationship to the Wider CFTS Stack

Software and automation sit across the other CFTS service layers rather than existing as a completely separate environment.

They may interact with:

  • network and internet services
  • DNS
  • firewalls and edge infrastructure
  • compute and virtualisation
  • storage and backup
  • monitoring
  • hosted services
  • support systems
  • documentation

This is part of the wider CFTS approach: treat the operating environment as connected components and use software where it makes those components easier to operate, support, or understand.