Azeez Lukman (Bigzeez)

Founder & Engineering Lead


> _Our journey From CI/CD Frustration to npm Package_


Ever had your CI/CD jobs fail because your database firewall blocks GitHub Actions' rotating IPs? We did too. What started as a recurring frustration in our development workflow became an opportunity to build something that now benefits the entire developer community.


This is the story of how we turned a daily blocker into an open source solution and what we learned along the way.


## The GitHub Actions IP Challenge


At Techengenes, we pride ourselves on efficient development workflows. But there was one issue that kept breaking our stride: **database access in CI/CD pipelines**.


GitHub Actions runners don't have static IP addresses. Every time our workflows ran, they could be coming from a different IP address. Meanwhile, our DigitalOcean managed databases (quite sensibly) had firewall rules that only allowed connections from trusted sources.


The result? Build failures. Lots of them.


```bash
Error: connect ETIMEDOUT 142.93.XX.XX:25060
    at Connection._handleConnectTimeout
    Pipeline failed: Database connection refused
```


Sounds familiar?


### Local Development Woes


The problem wasn't limited to CI/CD. Our distributed team was constantly running into the same issue during local development:

- Working from home office ✅ Database connects
- Switching to a coffee shop ❌ Database connection blocked
- Client meeting at their office ❌ Different IP, blocked again
- Back home ✅ Works again
- Plus, with ISPs assigning dynamic IPs to some team members ❌ Even working from home caused occasional connection blocks

Each of these cases meant manually updating firewall rules through the DigitalOcean dashboard. For a team that values automation and efficiency, this manual process was particularly frustrating.


### The "Quick Fix" Trap


Like many teams, we were initially drawn to the nuclear option: opening our database to `0.0.0.0/0` (all IPs). But at Techengenes, we believe security shouldn't be sacrificed for convenience. Opening database access to the entire internet wasn't just bad practice it was a non-starter.


**We needed a better solution.**


## Our Engineering Culture: Turn Blockers Into Building Blocks


At Techengenes, we have a core philosophy: **when we encounter friction that slows down our engineering velocity, we don't just work around it, we engineer it away for good.**


This mindset has served us well in building projects, where we consistently turn operational challenges into automated solutions. But it also means we hold ourselves to the same standard internally.


The database firewall issue was a perfect example of something that needed to be solved properly, not just worked around.


## Building the Internal Solution


### Version 1: The Quick Script


Our first approach was straightforward, we wrote a bash script that:

1. Detected our current public IP
2. Called the DigitalOcean API to add a firewall rule
3. Ran our deployment or development task
4. Cleaned up the firewall rule afterward

```bash
#!/bin/bash
# Get current IP
CURRENT_IP=$(curl -s https://ipv4.icanhazip.com)

# Add firewall rule
curl -X POST \
  -H "Authorization: Bearer $DO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"rules":[{"type":"ip_addr","value":"'$CURRENT_IP'"}]}' \
  "https://api.digitalocean.com/v2/databases/$DB_ID/firewall"

# Run our actual task
npm run deploy

# Cleanup (remove the rule)
# ... cleanup logic
```


This worked, but it had limitations:

- **Tightly coupled** to our specific project structure
- **No error handling** — failures left orphaned firewall rules
- **Manual IP cleanup** when things went wrong
- **No rule identification** — couldn't distinguish automated vs manual rules

### Version 2: The Enhanced Script


We quickly evolved the script to handle real-world complexity:

- **Multiple IP detection services** with fallbacks
- **Descriptive rule labeling** with timestamps and job IDs
- **Robust error handling** and automatic cleanup
- **Support for multiple database types** (PostgreSQL and Redis)
- **Verbose logging** for debugging

The script grew to several hundred lines and became genuinely useful. But it was still tied to our codebase.


## The "Aha" Moment


During a team retrospective, one of my colleagues made an observation that changed everything:

> "This script is really useful, but we can only use it within this project. What if we need database access for a different project? Or want to quickly test something locally without spinning up the entire codebase?"

With multiple projects and a distributed team we found ourselves needing the same database access solution across multiple codebases. As an automation-driven team, the idea of duplicating this script everywhere felt fundamentally wrong.


That's when we realized: **we needed this tool to be globally available.**


…not just for us, but potentially for other teams facing the same challenges.


## Research: Discovering the Gap


Before building a standalone tool, I researched the existing ecosystem for a solution we could leverage, but instead i discovered a gap:


### Existing Solutions (And Their Limitations)

1. **Official DigitalOcean SDK** - General purpose, requires significant boilerplate
2. **Terraform/Pulumi providers** - Great for infrastructure provisioning, not operational tasks
3. **`digitalocean-developer-firewall`** - Focused on cloud firewalls for servers, not database firewalls
4. **Generic API wrappers** - Low-level, require understanding of firewall API intricacies

### The Gap We Discovered


**No tool specifically addressed database firewall management for CI/CD workflows.**


The existing solutions either:

- Required too much setup for simple operational tasks
- Focused on infrastructure provisioning rather than runtime operations
- Addressed different types of firewalls (cloud/server vs database)
- Lacked CI/CD-specific features like cleanup and rule labeling
- More importantly, these tools don't automatically detect IP addresses

That’s when we realized had stumbled onto a genuine gap in the developer tooling ecosystem.


## Building `digitalocean-db-firewall`


### Design Principles


Based on our internal experience and research, we established clear design principles:

1. **Zero Configuration** - Should work with just cluster ID and API token
2. **CI/CD Optimized** - Handle dynamic IPs, cleanup failures, label rules
3. **Multi-Database** - Support PostgreSQL, Redis, and future database types
4. **Bulletproof Error Handling** - Never leave orphaned firewall rules
5. **Global Availability** - Installable and runnable anywhere

### Key Features


```bash
# Simple usage
npx digitalocean-db-firewall add --postgres-id abc123 --token $TOKEN

# Multi-database support
npx digitalocean-db-firewall add \
  --postgres-id abc123 \
  --redis-id def456 \
  --token $TOKEN

# Cleanup all CI-added rules
npx digitalocean-db-firewall cleanup --postgres-id abc123 --token $TOKEN
```


### Technical Implementation Highlights


**Intelligent IP Detection**: Uses multiple services with fallbacks


```bash
ip_services=(
    "https://ipv4.icanhazip.com"
    "https://api.ipify.org"
    "https://checkip.amazonaws.com"
    "https://ifconfig.me/ip"
)
```


**Smart Rule Labeling**: Identifies automated vs manual rules


```json
{
  "type": "ip_addr",
  "value": "192.168.1.100",
  "description": "GitHub Actions CI/CD - 2024-01-15T10:30:00Z - Job: 12345"
}
```


**Automatic Cleanup**: Removes rules on script failure


```bash
cleanup_on_exit() {
    if [[ "$ACTION" == "add" ]] && [[ $exit_code -ne 0 ]]; then
        # Remove any rules we successfully added
        # ... cleanup logic
    fi
}
trap cleanup_on_exit EXIT
```


## Publishing and Early Response


### The npm Package


We published [`digitalocean-db-firewall`](https://www.npmjs.com/package/digitalocean-db-firewall) as a free, open source tool. While it's still early days, we're excited to see:

- **Community adoption** from developers worldwide
- **GitHub engagement** from teams with similar challenges
- **Positive feedback** validating the problem space
- **Feature requests** for additional database types and enhancements

We'll be tracking metrics and community response as the tool gains traction, and we're committed to evolving it based on real-world usage patterns.


### Real-World Impact


The tool immediately improved our workflows:


**Before:**

- Manual IP updates when changing locations
- CI/CD failures requiring manual intervention
- Security vs convenience tradeoffs
- Time lost to operational friction

**After:**

- One-command database access from anywhere
- Zero CI/CD failures due to IP issues
- Maintained security without sacrificing productivity
- Focus on building features, not fighting infrastructure

## Lessons Learned


### 1. Internal Tools Often Solve Universal Problems


What feels like a unique challenge to your team is often experienced by many others. The response to our npm package confirmed that database firewall management is a widespread pain point.


### 2. Research Before Building


Investigating the existing ecosystem before publishing helped us:

- Validate there was a genuine gap
- Position our solution effectively
- Avoid duplicating existing functionality
- Identify unique value propositions

### 3. Design for Your Future Self


Building the tool as a standalone package (rather than just a global script) made it:

- More maintainable
- Easier to extend
- Shareable with the community
- A better reflection of our engineering standards

### 4. Open Source Creates Opportunities


Publishing the tool:

- Showcased our technical capabilities
- Generated positive attention for Techengenes
- Created networking opportunities with other engineering teams
- Established us as contributors to the developer community

## The Business Impact


This project exemplifies how Techengenes approaches technical challenges not just for ourselves, but for our clients:


### For Our Team

- **Improved productivity** through eliminated friction
- **Better security posture** without convenience sacrifices
- **Enhanced engineering reputation** through open source contribution

### For Our Clients

- **Demonstrates our problem-solving approach** — we build solutions, not workarounds
- **Shows our automation expertise** — turning manual processes into reliable tools
- **Proves our commitment to best practices** — security, maintainability, community contribution

### For the Community

- **Fills a genuine gap** in the developer tooling ecosystem
- **Saves time** for teams facing similar challenges
- **Raises the bar** for CI/CD database access patterns

## What's Next


The success of `digitalocean-db-firewall` has inspired us to look for other opportunities where we can turn internal solutions into community benefits:

- **Additional cloud providers** - AWS RDS, Google Cloud SQL firewall management
- **Enhanced automation** - Integration with more CI/CD platforms
- **Security improvements** - IP allowlist validation, audit logging
- **Enterprise features** - Team management, rule templates

## Try It Yourself


If you're dealing with similar database access challenges in your CI/CD pipelines, give our tool a try:


```bash
# Install globally
npm install -g digitalocean-db-firewall

# Or use directly
npx digitalocean-db-firewall --help
```


**GitHub**: [https://github.com/Techengenes/digitalocean-db-firewall](https://github.com/Techengenes/digitalocean-db-firewall)


**npm**: [https://www.npmjs.com/package/digitalocean-db-firewall](https://www.npmjs.com/package/digitalocean-db-firewall)



Company

Support

Company

Socials