Skip to content
DCoding logo DCoding Documentation

Infrastructure Changelog

2026-03-27

The NestJS backend that hosts dev.drospect.ai uses Prisma for database migrations. We found that drospect’s migration history was manually changed by:

  1. first deleting a migration (which had already been committed and applied on dev) and then
  2. adding a new migration which did what the deleted one had already done (when it was applied on dev), thus blocking us from applying new migrations.

Relevant information:

  • The 20250611152359_add_scopito_inspection migration was added via 4ed0fea and (presumably) applied on dev, but then deleted via 8fc6cf0
  • 8fc6cf0 added 20250611152359_add_scopito_inspection which broke migrations on dev

This issue was addressed by manually applying:

docker exec -it <contianer-id> sh
npx prisma migrate resolve --applied 20250611152359_add_scopito_inspection
npx prisma migrate deploy

UFW was configured to allow the drospect backend to send requests to our self-hosted NodeODM server:

ufw allow from 172.18.0.0/16 to any port 4000 proto tcp

because the backend makes direct HTTP request using the NODEODM_API_URL environment variable which apparently was configured to point to the server directly using the server’s IP address. A better fix would be to manage NodeODM via CapRover to have it running on the same Docker network as the backend. (This will be put on hold for now since we’re considering to move to GCP altogether.)

2026-03-23

We received a report from Hetzner that our database instance wasn’t behind a firewall. This meant that the PostgreSQL port was exposed and could be accessed from anywhere. This changelog entry outlines the changes we made to address this issue. See DROS-38 for more information.

Created back-ups for pg_hba.conf and postgresql.conf.

sudo cp /etc/postgresql/16/main/pg_hba.conf /etc/postgresql/16/main/pg_hba.conf.bak
sudo cp /etc/postgresql/16/main/postgresql.conf /etc/postgresql/16/main/postgresql.conf.bak

Updated pg_hba.conf to allow access from:

  • 172.18.0.0/16, which is the Docker network subnet (i.e., the docker_gwbridge subnet), and
  • our office IP addresses.
# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             postgres                                peer
local   all             all                                     peer
host    all             all             127.0.0.1/32            scram-sha-256
host    all             all             ::1/128                 scram-sha-256
host    drospect-dev    postgres        172.18.0.0/16           md5
host    drospect-dev    postgres        <office-ip>/32          md5

Reloaded the database config via:

sudo -u postgres psql -c "select pg_reload_conf();"

Updated the database connection string in CapRover from:

postgresql://postgres:<password>@157.180.55.60/drospect-dev

to:

postgresql://postgres:<password>@172.18.0.1/drospect-dev

Configured ufw to allow connections on port 22, 80, and 443. Connections on port 5432 (the port the database instance listens on) are allowed only for 172.18.0.0/16 and our office IPs.

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow from 172.18.0.0/16 to any port 5432 proto tcp
sudo ufw allow from <office-ip> to any port 5432 proto tcp
sudo ufw enable

In the future we should consider to

  • have the PostgreSQL instance running inside a Docker container like the rest of the services are, and
  • remove the office IP addresses and use SSH tunneling instead (we’re putting this on hold for now since team members don’t use SSH tunneling for DB access in their workflows).