Small Linux appliances do not become risky only when they fail.

They become risky when nobody knows what changed.

FILIP:OS started from a simple frustration.

Linux is powerful, but daily operations often turn into scattered scripts, manual fixes, SSH history, and notes that only make sense to the person who wrote them.

That is manageable for a while.

Then the appliance lives for a few months.

A service is adjusted. A package is updated. A config file is edited at night. A network setting is changed because something had to work immediately. A small exception is made and nobody writes it down properly.

None of these changes are necessarily wrong.

But together they create a bigger problem: the machine slowly becomes unknown.

At some point the question is no longer:

Is the server running?

The better question is:

Is this still the machine we think it is?

That is why FILIP:OS has an integrity module from the beginning.

Not as a big enterprise security product. Not as a SIEM replacement. Not as a dashboard that only works when everything is already healthy.

The integrity module is meant to answer a simple operational question locally:

What changed on this appliance?

The idea is deliberately boring.

FILIP:OS keeps a local baseline of important files, settings, and operational state. Later, the operator can compare the current system against that baseline.

In the simplest form, the command should feel like this:

check integrity

The appliance checks itself and gives a readable result.

For example:

[INTEGRITY] baseline: operational
Result: OK
Changed files: 0

Or, when something changed:

[INTEGRITY] baseline: operational
Result: CHANGED
Changed files: 3
Action: review before upgrade

That is not complicated.

That is the point.

A small appliance should not need a full central platform just to know whether its important files changed.

Central reporting is useful. Automation is useful. AWX, backup systems, monitoring, and dashboards all have their place.

But the node should understand itself first.

FILIP:OS is designed around that principle.

A local node should be able to answer:

  • what changed?
  • when did it change?
  • was it expected?
  • is the current state still clean enough to trust?
  • should I continue with an upgrade, backup, or configuration change?

This matters because many small environments do not have large infrastructure teams. They have one admin, one appliance, one urgent problem, and not enough time.

That is exactly where invisible changes become dangerous.

If network configuration changed, I want to know.

If service configuration changed, I want to know.

If a FILIP:OS module touched the system, that action should be logged.

If an administrator made a manual fix, it should not disappear into memory and shell history.

Integrity is not about preventing all change.

Change is normal. Systems have to be maintained.

The point is to separate expected change from mystery change.

Expected change can be documented, accepted, and turned into a new baseline.

Mystery change needs attention.

This is also why FILIP:OS output is intended to work for both people and automation.

For a human operator:

check integrity

For automation:

filipctl --output=json check integrity

The same action should be readable on a console and usable by tools like Ansible, AWX, monitoring, reporting, or incident workflows.

A technician needs a clear answer.

An automation system needs structured output.

Both should be looking at the same truth.

That is the kind of foundation I want for FILIP:OS.

Less guessing.

More visible state.

Small Linux appliances that can tell you what they are, what changed, and whether they are still safe to operate.

Integrity may not be the most glamorous feature.

But before you upgrade a machine, back it up, expose a service, troubleshoot an incident, or trust its state, you should first know what machine you are actually dealing with.

That is what FILIP:OS integrity is for.