Self-Hosted

What Sanchayam is a self-hosted multi-asset portfolio tracker. It tracks equity (Indian and US markets), mutual funds, crypto, bank balances, and real estate under one unified schema. It computes FIFO cost basis, realized P&L, and XIRR per holding and across the entire portfolio. It handles multiple currencies with automatic FX conversion. Multiple users can share a family portfolio view. Live: sanchayam.com - hosted version, request access and use it directly Backend: github.com/sagarnayak/sanchayamBackend-public Frontend: github.com/sagarnayak/sanchayamFrontend-public Why Most portfolio trackers are either too narrow (they handle equities but not real estate), too opinionated (they force a specific cost basis method), or they require handing your financial data to a third party. Sanchayam is self-hosted, schema-driven, and designed for the full breadth of assets a typical Indian investor actually holds: listed equities, unlisted holdings, mutual fund NAVs, crypto, bank balances across currencies, and illiquid real estate. ...

What MediaBridge is a self-hosted file management layer over AWS S3. It gives teams a proper interface for uploading, browsing, and sharing files across multiple S3 buckets without AWS console access and without distributing IAM credentials to individuals. It runs in production managing 33 S3 buckets. Backend: github.com/sagarnayak/mediabridgeBackend-public Frontend: github.com/sagarnayak/mediabridgeFrontend-public Why The access problem Content teams upload files constantly: images for a web app, PDFs for client portals, videos for a dashboard. Those files need to live in S3 and they need URLs. The question is how the team gets them there. ...

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. 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 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. ...