Build 1 publisher3 min readPublished Aug 18, 2026, 7:57 PM PDT

The First Firewall Rule Is a Cutover: One Allowlist Entry, One Dead Production App

A team's CI backup job allowlisted its runner IP on DigitalOcean managed Postgres. The database switched from credentials-only to allowlist-only, and production fell off the list it was never on.

The Engineer · Build desk

Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AI Send a correction

What happened

The team's DigitalOcean managed Postgres had no trusted-source rules at all, which by default means open to anything that has the connection string and credentials.
The droplet running their application talked to the database from a public IP, with no allowlist entry required.
Their backup pipeline temporarily allowlists the runner IP, runs pg_dump, then revokes the IP; the author describes this as the standard pattern used by basically every CI-driven DB job.
The new pipeline added one rule with the command: doctl databases firewalls add "$DB_ID" --rule "ip_addr:${RUNNER_IP}".
DigitalOcean flipped the database into enforcement mode the moment a single rule was added, moving it from 'anyone with credentials' to 'only IPs on the allowlist'.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

A team added a database backup pipeline that temporarily allowlists the CI runner's IP, runs `pg_dump`, then revokes the IP, which is the standard pattern for CI-driven database jobs ^[3]. The first run did all three steps correctly and took production down while doing it ^[4]^[6].

The setup before the pipeline is the part worth reading twice. Their DigitalOcean managed Postgres had no trusted-source rules at all, which in practice means open to anything holding the connection string and credentials ^[1]. The application droplet reached the database over a public IP and had never needed an allowlist entry ^[2]. Then the pipeline ran one command, `doctl databases firewalls add` with the runner's IP ^[4].

According to the team's account, DigitalOcean flipped the database into enforcement mode the moment that single rule existed ^[5]. The runner was on the list. The droplet was not, because there had never been a list ^[6]. The dump succeeded and the application returned 500s for every request for the duration of the window ^[7]. Traffic was dropped at the network layer, not the auth layer, so from the application's side the database had simply vanished ^[11].

The semantics are documented, after a fashion. The team eventually found a docs page saying trusted sources are enforced "when configured," where "configured" turns out to mean "any rule exists" ^[8]. There is no dashboard warning and no confirmation prompt at the transition ^[9]. That is the whole trap: a zero-to-one rule change is a security-model cutover, while every one-to-many change after it is merely additive ^[17]. The command looks identical in both cases.

Recovery is cheap once you know. Removing all rules returns the database to open mode ^[10], and adding the production droplet's IP permanently means later runner entries are just extra rows in an existing allowlist with no enforcement flip ^[12]. The team also switched from `add` to `append`, which has the same effect for a single rule but makes explicit that you are not overwriting the whole firewall ^[13].

The durable fix is a preflight, not a runbook note. Their workflows now resolve the production droplet's public IP, check it against `doctl databases firewalls list`, and exit non-zero with the exact `append` command if it is missing, so an operator has to add the rule once, deliberately, before any workflow can open a runner IP ^[14]. The same guard went into the backup, seed and restore workflows, everywhere trusted sources get mutated ^[15].

Worth checking on your own estate: whether any managed database is currently running with an empty trusted-source list, because that is the configuration where an innocuous-looking firewall call becomes an outage. This is one team's report, published on dev.to and originally on their own blog ^[16], so treat the exact enforcement behaviour as something to verify on a staging database before you rely on it either way.

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[5]
DigitalOcean flipped the database into enforcement mode the moment a single rule was added, moving it from 'anyone with credentials' to 'only IPs on the allowlist'.
ReportedSupportedSource: dev.to post by the team that hit the failure2 sources— create a free account to open them View cited source
[8]
The team eventually found a docs page stating that trusted sources are enforced 'when configured'; in practice 'configured' means any rule exists, and adding the first rule is the moment enforcement changes from off to on.
ReportedSupported2 sources— create a free account to open them View cited source
[1]
The team's DigitalOcean managed Postgres had no trusted-source rules at all, which by default means open to anything that has the connection string and credentials.
ReportedSupportedView cited source
[2]
The droplet running their application talked to the database from a public IP, with no allowlist entry required.
ReportedSupportedView cited source
[3]
Their backup pipeline temporarily allowlists the runner IP, runs pg_dump, then revokes the IP; the author describes this as the standard pattern used by basically every CI-driven DB job.
ReportedSupportedView cited source
[4]
The new pipeline added one rule with the command: doctl databases firewalls add "$DB_ID" --rule "ip_addr:${RUNNER_IP}".
ReportedSupportedView cited source
[6]
The production droplet was not on the allowlist because it had never needed to be, so the application instantly lost its database connection.
ReportedSupportedView cited source
[7]
The backup dump succeeded while the application returned 500s for every request for the entire window.
ReportedSupportedView cited source
[9]
There is no warning in the DigitalOcean dashboard, no prompt and no confirmation when adding the rule; the rule simply appears in the list.
ReportedSupportedView cited source
[10]
If all rules are removed, the database returns to open mode.
ReportedSupportedView cited source
[11]
During the outage window all non-allowlisted traffic was dropped at the network layer rather than the auth layer, so from the application's perspective the database had vanished.
ReportedSupportedView cited source
[12]
The immediate ops fix was adding the production droplet's IP to the allowlist before the pipeline runs again; once the droplet is on the list, the pipeline adding another runner IP is just one more entry in an existing allowlist with no enforcement-mode flip.
ReportedSupportedView cited source
[13]
The team used 'doctl databases firewalls append' rather than 'add', noting it has the same effect for a single rule but makes explicit that you are not setting the entire firewall.
ReportedSupportedView cited source
[14]
The permanent guard is a preflight step in every workflow that touches the firewall: it resolves the production droplet's public IPv4 via doctl compute droplet list, checks it against doctl databases firewalls list, and exits 1 with the exact append command if the IP is missing, so an operator must add the rule once manually before the workflow can run.
ReportedSupportedView cited source
[15]
The same preflight was added to every other workflow that touches the database firewall, including backup, seed and restore.
ReportedSupportedView cited source
[16]
The account was published on dev.to and was originally published on the author's own blog (Jo4 Blog).
ReportedSupportedView cited source
[17]
Because enforcement turns on when the first rule exists but subsequent rules only extend an existing allowlist, a zero-to-one rule change is a security-model cutover while every later addition is additive.
DerivedSupported1 source— create a free account to open them

Sources

Publishers whose own reporting we read for this story.

dev.to
1 article · August 18, 2026
DigitalOcean Postgres Has a Firewall Trap. We Walked Right Into It.

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

Builder

For builders, the cluster is a single dev.to write-up that reads as a copy-pasteable pattern: the offending 'doctl databases firewalls add' one-liner, the 'append' variant, and a full GitHub Actions preflight step that resolves the droplet's public IPv4 and exits 1 with the exact remediation command. The extra doctl detail (firewalls list supports neither --no-header nor --format, so awk column indexing shifts) is the kind of tooling contract gap that only surfaces in CI. Treat the zero-to-one firewall rule as a migration step in your pipeline design, not a parameter change.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence38: 0100
Concrete but single-sourced first-hand account
The account is specific and reproducible-looking: exact doctl commands, the awk parsing pitfall, and a complete preflight workflow step. But every claim traces to one self-reported post by the affected team, with no vendor documentation excerpt, no DigitalOcean response, and no independent reproduction of the enforcement-flip behavior in the cluster.
Adoption10: 0100
One disclosed deployment and fix
The only adoption evidence is a single team's disclosure that it hit this on a live DigitalOcean managed Postgres cluster and then replicated a preflight guard across its backup, seed and restore workflows. Nothing indicates how widely the platform behavior or the guard pattern is encountered elsewhere.
Hype gap+18: −100 understated0 aligned+100 overstated
Mildly overstated generalization
The framing ('DigitalOcean Postgres Has a Firewall Trap') generalizes one team's unverified experience into a platform defect, and the surprise partly stems from having run a production database open to anyone with credentials, a risk the post does not dwell on. The mechanics described are internally consistent and the remediation is understated rather than hyped, so the gap is modest rather than severe.
Incentives30: 0100
Practitioner self-publication, low commercial pressure
This is an author-published incident write-up on dev.to, cross-posted from the author's own blog, with no disclosed vendor relationship, sponsorship, or product being sold. The visible incentive is attention and reputation for a dramatic postmortem, which favors sharp vendor-fault framing but not fabricated technical detail.
Confidence42: 0100
Plausible mechanics, unverified generalization
Confidence is moderate: the incident narrative and remediation are detailed and self-consistent, and the failure mode (network-layer drops once an allowlist becomes non-empty) is mechanically plausible. It is capped by the absence of any second source, vendor confirmation, timing/impact figures, or evidence that other operators have hit the same cutover.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Managed Database Network SecurityFollow
CI/CD Pipeline Safety GuardsFollow
Production Incident PostmortemFollow
Cloud Platform UX FootgunsFollow
Infrastructure CLI ToolingFollow

The First Firewall Rule Is a Cutover: One Allowlist Entry, One Dead Production App

What happened

Why it matters

Claim ledger

Sources

Topics and entities

Topics

Entities

Claim ledger

Topics and entities

Topics

Entities

Perspective Coverage

Builder

Operator

Investor

Reality

Sources

What happened

Why it matters

Claim ledger

Sources

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Related stories

Claim ledger

Let Clarity write the post for you.

Topics and entities

Topics

Entities

Perspective Coverage

Builder

Operator

Investor

Reality

Sources

Related stories