Technical details about how the Abundly platform is built and secured.
System Architecture
Overview of the Abundly platform architecture
Components
| Component | Technology | Location |
|---|
| Web Portal | Vercel, Next.js/React | Vercel Edge Network |
| Agent Service | Google Cloud Run, Node.js | GCP europe-north2 (Stockholm) |
| Database | MongoDB Atlas | AWS eu-north-1 (Stockholm) |
| Task Queue | Google Cloud Tasks | GCP europe-north2 |
| File Storage | Google Cloud Storage | GCP europe-north2 |
Data Residency
All customer data is stored in EU data centers:
- Primary region: Stockholm, Sweden
- Database: AWS eu-north-1
- Agent Service: GCP europe-north2
- Serverless Functions: AWS eu-north-1
Data residency in the EU ensures compliance with GDPR and other European data protection regulations.
Encryption
| Type | Standard |
|---|
| At rest | AES-256 |
| In transit | TLS 1.2+ / HTTPS |
| Secrets | RSA-OAEP with SHA-256 |
Network Security
- All communication encrypted with TLS 1.2+
- HTTPS enforced for all endpoints
- CDN for web portal (Vercel Edge Network)
Secrets Management
| Component | Storage |
|---|
| User credentials | Encrypted in database |
| Platform secrets | GCP Secret Manager |
| Private keys | Separated from encrypted data |
Scalability
The platform is designed to scale:
- Event-driven architecture scales horizontally
- Cloud Tasks handles queueing and load management
- Database read replicas for query performance
- WebSocket management for real-time updates
Availability
| Feature | Implementation |
|---|
| Cloud-native resilience | Vercel and GCP automatic failover |
| Automated backups | Daily with point-in-time recovery |
| Backup retention | 9 months with cross-region replication |
| Health monitoring | Continuous monitoring with alerting |
Disaster Recovery
We maintain a documented Disaster Recovery Plan:
Protected Components
- Database: Automated daily backups with cross-region replication
- Source Code: Version-controlled with full history
- Secrets: Stored separately with documented recovery procedures
Recovery Objectives
| Objective | Target |
|---|
| RTO (Recovery Time) | 24 hours for critical services |
| Backup retention | 9 months |
Security Monitoring
| Activity | Approach |
|---|
| Infrastructure monitoring | Automated via GCP, MongoDB Atlas, Vercel |
| Alert configuration | Email notifications to technical team |
| Active monitoring | Daily dashboard review |
| Incident response | Critical alerts within 1 hour (business hours) |
Penetration Testing
- 📅 Annual third-party testing scheduled (starting 2025)
- Testing after major infrastructure changes
- Results used to improve security posture