Get Redactifire running.

Quick start

Each release ships a source tarball, CycloneDX SBOMs (Python and npm), and a SHA256SUMS file. Download the artifacts for your version from the Releases page, verify the checksums, then build the image and start the service:

sha256sum -c SHA256SUMS

tar xzf redactifire-vX.Y.Z-src.tar.gz
cd redactifire-vX.Y.Z

docker build --build-arg GIT_VERSION=vX.Y.Z \
  -t redactifire:vX.Y.Z \
  -t redactifire:latest \
  .

docker compose up -d

Redactifire keeps all data (jobs, policies, and the Decoder Ring) in a named Docker volume. If the target has no outbound internet access, see deploy/AIRGAP.md in the source tarball. It explains how to build the image on a connected host, export it, and load it on the air-gapped target.

There's no default admin account. Create one after first boot:

docker compose exec redactifire redactifire create-admin --username admin

Leave out --password and the command asks for it, so the password never appears in your shell history. Then open http://localhost:8000 and sign in.

Authentication

The web UI always requires you to sign in. Local accounts work out of the box through redactifire create-admin. If you run it again for an existing username, it resets that password, so you can also use it to recover a lost admin password.

LDAP or Active Directory sign-in and OIDC or SAML single sign-on are built in. Local accounts keep working whichever other methods you turn on.

Redaction modes

Each entity type gets one of these modes, either for all values in a policy or for one value as an override. Mask and its keep variants hide the value but keep its shape, and the same value always masks the same way, so a support agent can tell whether two log lines refer to the same thing. Pseudonymize replaces the value with a consistent fake one. Suppress removes it.

Supported entity types

Redactifire detects these entity types: email, ipv4, ipv6, phone, username, userid, group, hostname, sid, ssn, credit_card, api_key, and url. It can take username, userid, and group values from LDAP, so it recognizes real directory identities that match no pattern.

Policy configuration

A YAML policy controls all masking, and each job saves a copy of the policy it used, for audit. A policy sets the mode for each entity type, plus optional allow and deny lists:

entities:
  email:
    mode: pseudonymize
    allow_list:
      - "noreply@example.com"
    deny_list:
      - "*@internal.corp.com"

  ipv4:
    mode: mask_keep_1
    allow_list:
      - "127.0.0.1"

  ssn:
    mode: suppress

  hostname:
    mode: mask
    allow_list:
      - "localhost"

To use your own policy instead of the default in Docker, mount the file and set REDACTIFIRE_CONFIG_PATH to its path. docker-compose.yml has a commented example.

LDAP integration

Connect Redactifire to your directory so it recognizes real usernames and groups:

ldap:
  enabled: true
  server_uri: "ldap://your-dc.corp.com:389"
  bind_dn: "cn=redactifire-svc,dc=corp,dc=com"
  bind_password: "..."
  base_dn: "dc=corp,dc=com"
  user_id_attribute: "uid"   # or "cn"
  search_filter: "(objectClass=person)"
  use_tls: false

With no live LDAP access (for example, on an air-gapped network), set user_list_file instead, and group_list_file for security groups. Each is a plain text file with one user ID or group name per line.

How Redactifire learns

Redactifire doesn't use machine learning and never trains on your data. Some of what it learns applies only to the current job, and some carries over to later jobs. All of it stays in your instance's database.

Within a job

While a job runs, Redactifire learns names from the files themselves and redacts each one in every file in the job, including every file in a ZIP bundle.

Host names given by a key. A value after a key like hostname:, nodename= or fqdn: is treated as a host name, whatever its shape. Collector bundles often name the host once and then repeat it in dozens of other files. Names learned this way apply to that job only.

Names confirmed in your directory. A pattern can't tell a username like jsmith from an ordinary word. When LDAP is turned on, Redactifire checks the words in your files that look like identifiers against your directory, in batches. It never imports the whole directory. This runs whenever ldap.enabled is true, with no separate setting (see LDAP integration). Available in every tier.

Host names confirmed in your internal DNS. Short host names like jazzprod01 don't look like host names to a pattern. Redactifire looks up the names its host name pattern misses in your internal DNS, only within your own domains, and redacts the ones that resolve to your internal address ranges. You set this up with environment variables. The resolver and your domains are required, and Redactifire never looks up a name outside those domains:

REDACTIFIRE_DNS_RESOLVER=10.0.0.53
REDACTIFIRE_DNS_SEARCH_DOMAINS=corp.example.gov

If some internal hosts are outside RFC 1918 space (for example, an agency's own public address blocks), list those ranges in REDACTIFIRE_DNS_INTERNAL_RANGES. Each lookup exposes the name it looks up, so Redactifire never uses the host's own resolver, which usually forwards to public DNS, and it rejects any resolver that isn't internal. Available in every tier.

Across jobs

These carry over from one job to the next. Anything that changes what a job does is versioned, so you can always see which settings a past job used.

When an org-wide decision and a Profile decision disagree, an org-wide allow wins (an admin's explicit exemption); otherwise the more restrictive mode wins. Credentials, SSNs and card numbers can never be saved as allowed.

The LDAP and DNS caches keep each answer for 24 hours, including "not a real user" and "not an internal host", so a name that comes up again in other files or jobs costs nothing to check. If LDAP is unreachable, the job still runs with what's in the cache and records how many names it could verify, so you can see when a check was incomplete.

What isn't learning

Job history is a record for audit and review. Nothing in it is fed into later jobs.

What stays local

Everything Redactifire learns stays in your instance's database. LDAP queries go only to your directory server, and DNS queries only to your internal resolver. Redactifire sends nothing anywhere else.

Decoder Ring and audit trail Pro

The Decoder Ring records every redaction. It's a local table, kept for each job, that maps each original value to its replacement. Because it's as sensitive as the original data, Redactifire stores it apart from the sanitized output and never sends it anywhere. Each job also keeps its original text and sanitized output, so you can prove what was masked long after the job ran.

Custom branding Pro

Admins can change the web UI's logo, app name, and accent and navigation bar colors, or turn on a classification or environment banner. Use the banner to make a high-side deployment look different from a low-side one, or to match corporate branding. The settings are on the Theme page (admin accounts only) and apply everywhere, including the sign-in page, because a classification banner must be visible before anyone signs in.

The banner has its own background and text colors, and you can pin it to the top of the page, the bottom, or both. You upload the logo through the browser, so you don't need access to the host's file system.

FAQ

What happens to my data if my license lapses? A license never holds your data hostage. Job history, the Decoder Ring audit trail, and all sanitized output on the instance stay available. A lapsed license blocks new redaction jobs and turns off the API until you renew. It doesn't lock, hide, or delete anything already on disk. Data ages out only on the retention schedule you set, never because of license status.

Does anything leave my network? No. Redactifire makes no connections outside your network and can run air-gapped. There's no telemetry, and Redactifire never sends your logs, policies, or mappings anywhere.

Does Redactifire learn from my data? Only in your own instance. There's no machine learning and no training. It remembers decisions your reviewers save, lists your admins maintain, and which names it has confirmed against your own LDAP and DNS. None of it leaves your network. See How Redactifire learns.

Will the same value always redact the same way? Yes, within a job. The Global Identity Map (GIM) makes sure a value replaced in one file gets the same replacement in every other file in that job.

Can I exempt one specific value from an otherwise type-wide rule? Yes. Add the value to the allow list (for example, one email address a vendor needs to see). The rest of that entity type keeps its mode.