Prepared for Hassan Allam
Your data environment, in accounts you own. This proposal sets out what you provide, where information is stored, and how Sakneen will operate the application.
Explore the requirementsThis is the intended setup, subject to implementation, migration and joint acceptance before production activation. Final scope, service levels and responsibilities will be recorded in the operating agreement.
THE STARTING POINT
Hassan Allam provides the accounts and access. Sakneen then configures the database and the agreed cloud resources. Regions, sizing and permissions are confirmed together before provisioning.
Sakneen will configure the application database, users, collections and indexes within the access you approve. Choose either of the hosting options below; the shared requirements apply to both.
| Item | Proposed requirement |
|---|---|
| Version | MongoDB 8.x as the proposed baseline; final version confirmed during compatibility validation. |
| Topology | A production replica set with at least three data-bearing nodes, supporting transactions and change streams. This applies to either hosting option. |
| Access | Named setup access and a separate, least-privilege application identity. Sakneen will provide the access schedule. |
Start with a smaller dedicated tier for one client and grow with measured demand. M30 is a proposed baseline, not a capacity guarantee; planned imports and large workload spikes may need capacity increased in advance.
| Item | Proposed requirement |
|---|---|
| Starting tier | Atlas M30 General, with 8 GB RAM per node, is the proposed starting point for this single-client deployment. M40 is not required upfront. Confirm sizing against the migrated dataset, indexes, concurrent usage and background jobs before launch. |
| Auto-scaling | Enable compute and storage auto-scaling so Atlas can increase capacity as demand grows. Use M30 as the minimum compute tier and agree the maximum tier before launch. Enable downscaling where supported and where the stored data fits the smaller tier. |
| Capacity & cost | Agree storage sizing, scaling settings and budget alerts with Hassan Allam. Scaling changes the bill. Storage growth can require a higher tier and raise the configured maximum, so that maximum is not an absolute spending cap. |
MongoDB can run on Hassan Allam’s own infrastructure instead of Atlas. Sakneen connects the application to the agreed replica set and manages the application-level database configuration.
| Item | Proposed requirement |
|---|---|
| Deployment | Use Hassan Allam-owned dedicated servers or VMs running a three-node, data-bearing MongoDB replica set. Place nodes on separate physical hosts or independent failure domains; multiple VMs on one physical server do not protect against that server failing. |
| Sizing & growth | Agree reserved CPU, RAM, SSD capacity and disk performance after workload validation. M30 is an Atlas tier, not a self-hosted server specification. Hassan Allam provisions additional capacity or resizes servers as needed; Atlas auto-scaling does not apply. |
| Operations owner | Hassan Allam operates the servers and replica set, including server security, OS and MongoDB maintenance, monitoring, backups, restore testing, availability and capacity upgrades. These server operations are outside Sakneen’s scope. |
The client project holds the agreed data services. The application runtime and background workers remain hosted by Sakneen. This project is required with either MongoDB hosting option.
| Item | Proposed requirement |
|---|---|
| Ownership & billing | One project owned by Hassan Allam, with active billing. No buckets, datasets or queues need to be created in advance. |
| Resources in scope | Cloud Storage, BigQuery, Cloud Tasks, Cloud Logging, Cloud Monitoring, and agreed identity and secret-management resources. |
| Provisioning access | Permissions to create and manage the agreed services and their access policies. Any elevated setup access is separately agreed. |
| Ongoing access | A named engineering contact and a separate runtime identity, each limited to its responsibilities. Sakneen will send the identity details securely. |
| Organisation policies | Confirm that approved external identities, required service agents, resource regions and network connections are permitted. |
Provisioning access and day-to-day application access are separate. We will agree the necessary permissions; unrestricted organisation-wide access is not a prerequisite. Credentials will be exchanged through an approved secure channel.
YOUR DEDICATED DATA ENVIRONMENT
The following are the target destinations after migration and acceptance. Both application records and the supporting operational stores are included in the isolation checks.
| Information | Client-owned destination |
|---|---|
Application records Users, roles, leads, units, projects and organisation settings. | DATABASEYour MongoDB cluster |
Operational application state Background-job payloads and ledger, scheduled-job state, cache, locks, real-time coordination and conversation checkpoints. | DATABASEYour MongoDB cluster |
Reporting and retained history Reporting data and configured audit, activity and completed-job archives. Recent operational history may also remain in MongoDB. | WAREHOUSEYour BigQuery datasets |
Files and documents Media, generated PDFs, retained archive objects and controlled temporary processing files, as agreed for each workflow. | STORAGEYour Cloud Storage buckets |
Background dispatch Queue scheduling and task references. Application job payloads and execution history are held in the dedicated data stores above. | QUEUECloud Tasks in your project |
Application and request logs Delivered to your log bucket under the agreed retention policy. Routing, source exclusions and any other copies are verified before launch. | LOGGINGYour Cloud Logging bucket |
Metrics for your own data services remain with your providers. Application metrics originate in Sakneen’s hosting environment. Client-facing dashboards or exports, alert recipients, uptime visibility and any retained operational copies will be agreed and validated before go-live.
Backups, temporary files and archived records follow the agreed region and retention policy. Document rendering, private-file delivery and all archive destinations are part of acceptance—not only the primary database.
TRANSPARENT BY DESIGN
Dedicated storage is one part of the service. The following processing, identity and operational boundaries will be documented explicitly; they are not a promise that all information stays exclusively inside your accounts.
The application and background workers will run in a dedicated Sakneen-operated environment and process your data to deliver the product. The hosting region and approved network paths will be agreed. If your requirement also covers where processing occurs, we will confirm that before implementation.
Users can continue signing in through Sakneen’s Auth0 identity service. Identity profiles, authentication records and relevant profile metadata remain with that service. Application user records, roles and permissions will reside in your dedicated database. Identity, access and account-lifecycle requirements are confirmed during setup.
Google Cloud’s protected _Required bucket retains mandatory audit logs for 400 days in the project where those records originate. Its retention cannot be shortened. These records can include administrator identities, resource names and action metadata. They are separate from the application and request logs routed to your project.
The application needs authorised access and configuration identifying your resources. We will agree where secrets are held, who can access them and how they are rotated or revoked. Managed or short-lived credentials will be used where supported; long-lived exported keys are not assumed to be necessary for every service.
Analytics, AI and AI tracing, messaging, CRM integrations, document processing, support and monitoring may involve additional providers. Before go-live, each enabled service, account, data category and retention arrangement will be approved. Shared analytics or tracing destinations will be disabled, replaced with client-owned accounts, or explicitly accepted.
Using a client-owned vendor account still involves processing by that vendor. Any such processing remains part of the agreed data-handling scope.
A CLEAR OPERATING MODEL
Hassan Allam owns its infrastructure accounts and data. Sakneen owns the application and operates the resources agreed in scope. The proposed division below will be confirmed in the operating agreement.
A data-layer outage can affect the application. The operating agreement should identify a named owner and escalation route for each dependency.
FROM PROPOSAL TO PROVISIONING
Use this checklist to prepare the infrastructure handoff. Checkmarks are personal planning notes—not confirmation that infrastructure has been verified or the proposal accepted.
SAKNEEN DELIVERY & JOINT ACCEPTANCE
Validate every database, worker, queue, file, archive and conversation-state destination. Unavailable client data services must not trigger a fallback to shared Sakneen storage.
Reconcile records, files, retained history and pending jobs. Agree the migration window and rollback procedure.
Test access denial, isolation, document delivery, log routing, monitoring, approved external services and restore compatibility.
Confirm the operating agreement, named owners, incident contacts and acceptance results before enabling the dedicated production environment.
Confirm your technical contact and the checklist above with your Sakneen contact. We will align the access schedule, agreed scope and provisioning plan before work begins.
Review the requirements