CloudPrem

cloudprem is a single tenant deployment of archbee that runs entirely inside an aws account you own and control your documentation, your database, your files, and your backups all live within your cloud boundary archbee operates the application for you, but your data stays in your account this model is sometimes called bring your own cloud (byoc) you get the full archbee product as a managed service, with the data residency, isolation, and compliance posture of running it in your own infrastructure what cloudprem is architecture a single tenant, dedicated deployment ensuring complete environment isolation infrastructure hosted within your own aws account in a region of your choosing data residency all primary data, including documents, databases, and backups, remains inside your cloud boundary operations fully managed by archbee devops to ensure system health, updates, and recovery because the deployment lives in your account, you retain full visibility and control over the underlying resources, while archbee handles the operational burden of running the product how we deploy archbee cloudprem is provisioned as code using the aws cloud development kit (cdk) everything networking, database, content delivery, compute, and the application itself is defined in versioned infrastructure templates and deployed into your aws account there is no manual, click through setup the deployment is organized into a set of coordinated stacks networking an isolated vpc spread across up to three availability zones, private subnets, security groups, and a load balancer database amazon aurora serverless v2 (single writer configuration) and amazon elasticache for redis, in private subnets cdn amazon s3 object storage and an amazon cloudfront distribution compute the amazon ecs cluster (aws fargate) that runs the application main the archbee application services, load balancer routing, secrets, and logging releasing new versions archbee ships application updates from external private runners (using pnpm run build and cdk deploy), which authenticate into your aws subaccount to update ecr and cdk targets rollouts are health checked new tasks must pass an application health check before old tasks are retired, so in normal operation deploys complete without downtime the application runs as three independently managed service types on aws fargate app the next js frontend api the express backend worker background jobs (not internet facing) application traffic reaches the services over https, terminated at an application load balancer with an acm managed tls certificate, and cloudfront sits in front of the load balancer for content delivery release cadence archbee delivers updates to your cloudprem deployment on a regular weekly cadence, keeping the application current with new features, fixes, and dependency updates archbee manages the release process so you don’t have to operate it yourself when a critical fix or security patch is required, archbee ships it as soon as it is ready, outside the normal weekly window the principle is simple routine improvements roll out weekly; urgent fixes arrive immediately what archbee devops does the archbee devops team manages the application lifecycle on your behalf by lifecycle management handling all version upgrades, dependency updates, and security patches sla commitment providing guaranteed service availability as defined in your service agreement incident response managing comprehensive backup, restore, and failover procedures you own the aws account and its guardrails; archbee owns the application running inside it access model archbee operates on a least privilege, no standing access basis archbee devops has no standing access to your application data, your application logs, or your database there is no always on operator path into your data when an investigation requires access, archbee requests it access is granted only after you explicitly approve it granted access is time bound and audited it expires automatically, and the activity is recorded the controlled path for any database level work is a bastion host inside your vpc logs are routed directly to aws cloudwatch; inspecting logs does not use the vpc bastion host but requires approved access to the aws console or cloudwatch apis every database specific access therefore flows through a single, auditable, approval gated channel that you control disaster recovery archbee cloudprem combines aws native resilience the inherent durability and failover properties of the managed services it runs on (aurora, s3, elasticache, ecs fargate) with archbee’s operational backup and recovery procedures some of the protections below are built into the aws services themselves; others are operational commitments archbee configures and runs for your deployment a few terms used below region a geographic location of aws (for example, the eastern united states) availability zone (az) one of several independent data centers inside a region backup a saved copy of data that can be restored later how your data is protected multi az database storage durability amazon aurora automatically maintains six copies of your data across three availability zones, independent of how many database instances are running this storage layer redundancy means the loss of an individual disk or az does not lose data automatic failover archbee relies on aurora’s native storage layer redundancy for data durability for compute availability, aurora recreates the writer instance in the event of failure; compute level failover expectations are defined in your service agreement continuous, point in time backups aurora continuously backs up the cluster volume and supports point in time restore within its configured retention window, which lets us undo an accidental change or deletion archbee configures the retention window for your production deployment; confirm the exact number of days against your service agreement cross region backup copies (operational commitment) this is an optional operational configuration where contracted, archbee configures the replication of backups to a second, geographically separate region so your data can be recovered if an entire region becomes unavailable long term archive (operational commitment) where contracted, archbee takes a periodic full backup retained for long term archival the frequency and retention period are defined in your service agreement durable file storage uploaded files, images, diagrams, document revisions, and exports are stored in amazon s3, which is designed for 99 999999999% (eleven 9s) of object durability by keeping multiple redundant copies across availability zones automatically content is delivered globally through amazon cloudfront resilient cache in production, the redis cache runs in multi az mode with a replica and automatic failover, so a single node failure does not interrupt service self healing compute application tasks run on aws fargate, spread across multiple availability zones behind load balancer health checks if a task becomes unhealthy or an az has a problem, the load balancer removes the affected task from rotation and ecs automatically replaces it no manual intervention required document version history each time a document is saved, earlier versions are retained in dedicated, durable storage, so previous copies of a document can be recovered through archbee’s restore process encryption everywhere all data is encrypted in transit (tls 1 2 or higher) and at rest s3 objects are encrypted with a customer managed aws kms key with automatic annual key rotation, and the cache is encrypted at rest and in transit ai inference archbee's ai features run on foundation models hosted in amazon bedrock, invoked within your own aws account and region prompts, document content, and model responses never leave your cloud boundary there is no call to any external ai provider and no data is used for model training inference traffic stays inside your vpc over aws's private network, governed by the same kms encryption and least privilege access controls as the rest of your deployment recovery scenarios situation how archbee recovers data changed or deleted by mistake restore the database to a moment just before it happened, within the configured point in time retention window a whole region goes down where cross region backups are configured, rebuild the database from the copy kept in the second region and bring the service back online a file version is lost or overwritten restore the previous version through archbee’s document version history restore process an application instance or availability zone fails the load balancer routes around the failure and ecs fargate automatically launches a healthy replacement across azs shared responsibility cloudprem is a partnership responsibilities are clearly split you own archbee owns the aws account and its guardrails the archbee application and its updates approving and scoping any access requests deploys and the weekly / out of band release process your data, residency, and compliance boundary the uptime sla (per your agreement) disaster recovery (backups, restore, failover) in short you control the cloud and the data; archbee runs the product inside it and is accountable for keeping it available and recoverable