Posts

Part of the PurelyManage series. This is the end-to-end deployment guide for PurelyManage. The backend runs as a Node.js process managed by systemd. The frontend is a static React build served from S3 via CloudFront. nginx handles TLS termination and reverse proxying for the backend. Both repos are on GitHub: Backend: github.com/sagarnayak/purelymanageBackend-public Frontend: github.com/sagarnayak/purelymanageFrontend-public Prerequisites Ubuntu (or any Linux with systemd) Node.js 18 or later PostgreSQL (any recent version, local or remote) nginx certbot (for TLS) imapsync (only if you need the migration feature, see the previous post) Backend Setup Clone the repo and install dependencies: ...

Part of the PurelyManage series. Installing imapsync imapsync is a Perl script. The version in most Linux package managers is years out of date and will fail on modern IMAP servers with current TLS requirements. Install it from the GitHub source instead. First install the Perl dependencies via apt: sudo apt-get install -y \ libauthen-ntlm-perl libcgi-pm-perl libcrypt-openssl-rsa-perl \ libdata-uniqid-perl libdigest-hmac-perl libdist-checkconflicts-perl \ libfile-copy-recursive-perl libfile-tail-perl libio-compress-perl \ libio-socket-inet6-perl libio-socket-ssl-perl libio-tee-perl \ libjson-webtoken-perl liblockfile-simple-perl libmail-imapclient-perl \ libmodule-scandeps-perl libnet-ssleay-perl libpar-packer-perl \ libreadonly-perl libregexp-common-perl libsys-meminfo-perl \ libterm-readkey-perl libtest-mockobject-perl libtest-pod-perl \ libunicode-string-perl liburi-perl libwww-perl Then download imapsync directly from GitHub and make it executable: ...

Part of the PurelyManage series. The migration system in PurelyManage wraps imapsync and adds a job queue, a UI, and a few quality-of-life features on top. This post covers the job system from the user side: how jobs are created, run, monitored, and managed. The imapsync installation and the async job architecture under the hood are covered in the next post. Server Configuration Before running any migration you need to add IMAP server definitions. A server definition stores only the connection details: host, port, and whether to use SSL. Credentials are entered per-job, not per-server, so you can reuse the same server config across many migrations without re-entering connection details each time. ...

Part of the PurelyManage series. The Problem Migrating an organization’s email means moving every mailbox from the old provider into PurelyMail. Each mailbox requires the source IMAP credentials: the email address and password the user logs in with on the old system. The naive way to collect these is to email everyone a spreadsheet and ask them to fill in their passwords. That spreadsheet then sits in someone’s inbox or a shared drive, plaintext, accessible to anyone who can read it. It is also error-prone: users mistype passwords, the admin has no way to know if a credential is correct until the migration job fails. ...

Part of the PurelyManage series. The Naive Approach Breaks at Scale The first version of the Domains page rechecked every domain on every page load. The logic was simple: call updateDomainSettings with recheckDns: true for each domain, then call listDomains to get the fresh DNS status. That is N+2 API calls per request where N is the number of domains. With the dashboard set to auto-refresh every 60 seconds: 50 domains × 52 API calls × 60 requests/hour = ~3,000 API calls/hour This is both wasteful and fragile. Most domains are healthy most of the time. Rechecking 50 domains every minute to confirm they are still green is unnecessary. And if PurelyMail ever introduces rate limits, this approach is the first to break. ...