Seemi Cloud Concepts

1. Introduction

Seemi Cloud is a developer-focused cloud platform for deploying and operating containerised applications, open-source services, databases, analytical platforms, AI development environments, and S3-compatible object storage.

The platform is designed around a small number of reusable concepts:

Tenants provide the main account, billing, and administration boundary.
Resource groups organise related workloads and provide an access-control boundary.
Components represent deployed services such as containers, databases, applications, and supporting resources.
SKUs define supported product configurations, included resources, operational behaviour, and pricing.
Regions and nodes determine where components run and where persistent data is stored.
Human identities and service principals provide governed access for people, applications, scripts, and AI agents.
Backups and recovery points protect eligible application data according to the selected SKU and configuration.
APIs and MCP tools allow supported infrastructure operations to be automated.

This document explains how these concepts fit together. Product-specific details, supported versions, resource requirements, backup tooling, and limitations should be maintained separately in the SKU Documentation.

This document describes the intended Seemi Cloud operating model. The portal, applicable SKU description, pricing shown before provisioning, Terms of Service, and any written tenant-specific agreement remain authoritative where they differ from general documentation.

2. Platform architecture

2.1 Control plane and workload plane

Seemi Cloud can be understood as two broad layers.

The control plane is responsible for activities such as:

Tenant and user administration.
Resource-group management.
SKU discovery and pricing information.
Component provisioning and lifecycle operations.
Access-control decisions.
Usage metering and billing records.
Backup scheduling and recovery workflows.
Audit and operational records.
Serve as the main authentication provider for backplane, nodes and any containers utilizing forward authentication.
API and MCP request handling.

The workload plane also referred to as nodes refers to the infrastructure on which customer components run. Depending on the selected SKU, this may include:

Containers running customer or catalog images.
Persistent application volumes.
Database data directories.
Service-specific containers and supporting processes.
Network endpoints and reverse-proxy.

Separating these concepts is important. A control-plane record describes and manages a component, while the workload itself runs on regional infrastructure. Deleting, stopping, recreating, restoring, or migrating a workload may therefore involve both control-plane state and workload-plane operations.

2.2 Regional infrastructure

Compute workloads run on Seemi-managed nodes located in supported compute regions. Current public compute regions include:

Amsterdam, Netherlands.
Singapore.
Montreal, Canada.
Los Angeles, United States.

S3-compatible storage is available in a broader set of storage regions. A compute region and an object-storage region are separate selections. The S3 storage region is not always the same physical facility as the compute region. Infact to mandate segregation of concern, limit blast radious in case of incidents, Seemi Cloud prefers offsite S3 storage to be used for container backups.

For example, a component running in Amsterdam may use a disclosed S3 backup location in Frankfurt. Customers should review the region and backup placement shown for the applicable service before provisioning.

2.3 Shared infrastructure and isolation

Seemi Cloud uses shared infrastructure unless a dedicated arrangement is expressly stated. Shared infrastructure means that underlying servers, networks, storage platforms, or management systems run container workloads owned by different tenants while logical and technical controls separate customer workloads.

Isolation measures include:

Tenant and resource-group authorization checks for every action being performed.
Restricted container capabilities.
Controlled volume assignment.
Virtual container networks restricting traffic within resourcegroup or reverse proxy.
Restricted administrative access.
No customer access to the host container-runtime socket.
No privileged container mode.

Shared infrastructure does not mean that one tenant is permitted to inspect or manage another tenant’s resources. Attempts to bypass isolation controls are restricted via engineering and administrative controls.

2.4 Dedicated enterprise capacity

Some workloads require resources beyond the public SKU catalogue. Subject to technical and commercial review, Seemi engineering may be able to provide:

Custom CPU and memory combinations.
Larger underlying server nodes.
Tenant-dedicated nodes.
Custom network exposure.
Bespoke backup and retention arrangements.
Multi-node application architectures.
Assisted migration and deployment engineering.

Public estimator limits do not necessarily represent the largest architecture Seemi can support. Enterprise customers can contact cloud.support@seemi.net to discuss requirements.

3. Tenants

3.1 What is a tenant?

A tenant is the primary Seemi Cloud account boundary. It normally contains:

Tenant identity and profile information.
Authorized users.
Service principals.
Resource groups.
Components.
Usage records.
Billing statements and invoices.
Payment settings.
Audit and operational records.
Tenant-level configuration.

A customer may operate more than one tenant. Each tenant is administered, accepted, metered, and invoiced separately.

3.2 Tenant acceptance

Each tenant requires acceptance of the applicable Seemi Cloud Services Agreement. Seemi retains the agreement version, timestamp, accepting identity, and related audit information associated with acceptance.

A person accepting for an organisation must have authority to bind that organisation. Customers are responsible for maintaining accurate organisation, contact, billing, and tax information.

3.3 Tenant ownership and administration

Tenant-level administrators should be limited to people who need broad administrative access. Tenant administrators may be able to:

Invite or remove users.
Assign resource-group access.
Create or remove service principals.
View billing and usage.
Create resource groups.
Provision or delete components.
Access tenant-wide settings.
Review audit information.

Customers should maintain at least two appropriate administrative contacts for important production tenants so that access does not depend on one individual identity. Its worth noting that an account with L3 Access on a tenant can perform all administrative functions in that tenant, including permanent deletion of components.

3.4 Multiple tenants

Separate tenants may be useful when organisations need strong separation between:

Different legal entities.
Production and non-production environments.
Internal and customer-managed environments.
Different billing owners.
Different operating teams.
Different contractual arrangements.

A tenant should not be treated as a lightweight folder. It is a higher-level account and contractual boundary. Resource groups are usually more appropriate for organising workloads within the same customer and billing relationship.

4. Resource groups

4.1 Purpose

A resource group is a logical grouping of related components within a tenant. It is also an access-control boundary.

Typical resource-group models include:

One resource group per application.
One resource group per environment, such as development, testing, staging, or production.
One resource group per client managed by an agency.
One resource group per business unit.
One resource group for a related application stack, such as an application, database, cache, and message broker.
For components running within a single cloud node, all components within same resource group share a common docker network and can communicate with each other without exposing a service to the public internet.

4.2 Access inheritance

Access assigned at resource-group level apply to the components within that resource group. This allows a tenant administrator to grant a team access to a related set of resources without granting access to the entire tenant.

Before assigning access, consider:

Whether the user needs read-only visibility or operational control.
Whether the user should create billable resources.
Whether the user should be able to stop, restore, or delete components.
Whether the resource group contains sensitive production workloads.
Whether to create service principals and assign access to it for for automation.

4.3 Resource-group design guidance

Keep resource groups understandable and aligned to operational ownership. Avoid putting all components in one large resource group if different teams or environments need different permissions.

A default resource group ID is assigned by platform during creation, end users can assign a human readable description for resource groups for better visiblity.

Names should avoid secrets, personal data, or information that should not appear in audit and billing records.

5. Components

5.1 What is a component?

A component is a deployed or managed resource in Seemi Cloud. Examples include:

A container(i.e PostgreSQL or a container running a custom image).
An S3-compatible storage account.
Future catalogue services(i.e Purchased domains, Licenses, AI Tokens).

A component has a lifecycle, configuration, regional placement, resource allocation, access rules, usage records, and potentially persistent data. The component is uniquely identified by an InfraComponentID across the platform. This is a combination of TenantID, ResourceGroupID and ComponentID.

5.2 Component lifecycle

A typical component lifecycle includes:

Configuration: Select the SKU, region, resource group, size, storage, and supported options.
Provisioning: Seemi Cloud creates the required workload and supporting configuration.
Running: The service is available subject to its health, configuration, dependencies, and network exposure.
Updating: The image, configuration, resources, or supported settings may be changed.
Stopping: Compute execution may stop while allocated storage, configuration, and supporting resources remain.
Starting: A stopped component is returned to active execution.
Backing up: Eligible data is protected according to the selected backup configuration.
Restoring: Data is restored into the supported target workflow.
Migrating or recreating: The component may be redeployed on another node or from a recovery point.
Undeploying: The active component is removed from node, its local volumes/configurations deleted. Undeployed containers can be restored using backups on same or different nodes within same region.
Deleting: Deletion is only possible after undeployment. Post Undeployment Seemi Cloud can enforce a cooldown period before allowing deletion. Deletion removes all backups held in Seemi’s S3 infrastructure for that component. This is an irreversible operation and requires L3 access on the component(or a higher level object in the component heirarchy).

5.3 Component state

The control plane may show transitional states such as:

Draft
AwaitingComboSKUSubmission
AwaitingNodeSelection
AwaitingDeployment
Deployed
Undeployed
Deleted

Avoid submitting repeated lifecycle requests while an operation remains in progress. A component may require time for image retrieval, volume attachment, health checks, DNS updates, proxy configuration, or restoration. During this time, customers can view the component Tasks to understand status of various platform tasks being executed on the component.

5.4 Stopped components and billing

Stopping a component is not the same as deleting it. A stopped component may retain:

Persistent disk allocation.
Backup allocation.
Configuration.
Reserved capacity.
IP, routing, or domain configuration.
Stored images or supporting resources.

For this reason, stopped components remain billable according to the applicable SKU pricing. Undeployment of a container would stop the daily billing for computing costs. Full Deletion of the component fully eliminates the capacity occupied by the container and it is no longer billed.

5.5 Undeployment & Deletion

Undeployment is the first step towards deletion. A cooldown period may be applied before delection is allowed. Post Undeployment customers can only restore from existing backup snapshots. A full Delete erases all data including backups for that componet and is irreversible. Before Undeployment:

Export important application data.
Perform an additional backup for the component from Container details page. We recommend backing up data to independant locations aswell for mission critical datasets.
Test recovery where appropriate.
Review dependent workloads.

Undeployment is typically applicable for container workloads. For S3 Storage accounts, direct deletion is possible and is not reversible.

6. SKUs and resource sizing

6.1 What is a SKU?

A SKU is a published service package or billing unit. A SKU may define:

Product type and version.
Included vCPU.
Included memory.
Included disk.
Supported regions.
Backup method.
Network behaviour(Whether access from WAN is allowed, Whether Forward Auth or Cloudflare Edge is supported).
Image Details(registry, version).
Price and billing unit.

The SKU shown in the portal before provisioning is the definitive configuration for that order.

6.2 Predefined and custom SKUs

A predefined SKU uses a tested combination of CPU, memory, and product configuration. For many catalogue services, memory is linked to the selected tier and is not individually adjustable. Disk and backup capacity donot have any hard caps imposed by the platform and any overage will be billed inline with specified pricing.

A custom container SKU provides more flexible resource selection. Public estimator limits may apply, such as:

Up to 24 vCPU.
Up to 120 GB RAM.

Larger configurations may be available through Seemi engineering.

6.3 Included resources and overages

For compute services, a vCPU allocation may include a standard amount of RAM, SSD storage, and backup capacity. Additional usage is priced according to the pricing configuration.

The estimator should be treated as indicative. The portal configuration and final invoice prevail because actual billing may depend on:

Region.
Quantity.
Component activation dates.
Usage duration(days).
Additional disk.
Additional S3 Storage usage for Backups.
Egress overages.
Taxes as applicable on invoices issued by Seemi’s appointed legal entity during tenant creation.
Discounts or credits.
Tenant-specific terms.

6.4 Free SKUs

A free SKU is explicitly identified as free in the pricing configuration. Free status should not be inferred only from a product name or small resource size.

Free compute SKUs include a defined base CPU, memory, disk at zero cost. Usage beyond the included allowance(egress, backup storage, local disk) may be billable.

Free SKUs are intended for development, testing, evaluation, and early product exploration. Free SKUs:

Do not have an availability SLA.
Do not include guaranteed support.
Must not be the only location of important data.
Are free but still require payment-method verification. Free SKUs are disabled incase if no payment method is added to the tenant within 2 week of tenant creation.
Offering in limited count per Tenant to prevent abuse.
have limited region wise availability.
maybe unavailable due to capacity constraints.in regions that are over utilized.May be changed or withdrawn with appropriate notice where applicable.

6.5 Sizing guidance

Choose a SKU based on application behaviour rather than only the minimum resources required to start a process.

Consider:

Normal and peak CPU usage.
Memory used after caches warm up.
Database working set.
Concurrent users and requests.
Background jobs.
Index creation and maintenance.
Backup and restore resource requirements.
Temporary disk usage.
Log growth.
Software updates.
Future growth.

For production workloads, allow operational headroom. A component that merely boots at a given size may not provide reliable performance under load. Do note that the platform provides limited memory headroom in the form of disk swap, this is not a substitute for adequate RAM allocation and excessive memory usage can trigger OOM kills and container restarts.

As mentioned earlier, the platform does not apply hard limits on disk usage or egress and overages are charged according to pricing schedule.

7. Compute regions and placement

7.1 Selecting a region

Region selection affects:

Latency to users and dependent systems.
Data-residency considerations.
Regional pricing.
Backup placement.
Connectivity to third-party systems.
Available capacity and SKU support.
Recovery and migration design.

Choose a region close to the workload’s primary users or data sources unless legal, architectural, or integration requirements indicate otherwise.

7.2 Region codes

Seemi may use short region codes in the portal and APIs, for example:

AMS for Amsterdam.
SIN for Singapore.
MTL for Montreal.
LAX for Los Angeles.

Use the exact region identifiers returned by the portal or API rather than assuming a code.

7.3 Node placement

A region contains multiple compute nodes. A component is placed on a suitable node based on the platform’s scheduling and capacity rules.

Node placement may consider:

Available CPU and RAM.
Storage capacity.
Maintenance state.
Operational constraints.

Customers should not assume that two components in one region are on the same physical node. For Specific container SKUs, the end users can backup, undeploy and redploy containers in a specific node of their choice(subject to sufficient capacity in that node). If the customer workload requires placing multiple components within single node, support team can be involved to provision ‘Tenant Owned’ nodes where no other tenants are allowed to deploy on that node.(Special pricing applies for Tenant Owned nodes)

7.4 Failure domains and blast radius

A node is an important failure domain. Seemi Cloud architecture aims to reduce the effect of a single failure through controls such as:

Logical separation of tenants and resource groups.
Restricted container privileges.
Separation between active workloads and backup storage.
Ability to restore or recreate eligible components on another node.
Regional infrastructure controls.
Platform monitoring and operational response.

A single-instance component is not automatically highly available. Workloads requiring multi-node application availability should use an architecture specifically designed for that purpose. Stateless containers that donot require any bind/volume mounts can achieve higher availability and benefit from automated redployment if a node fails or goes into a maintainence state. Stateful workloads such as databases, caches, and message brokers typically involve manual intervention to restore last backups into a new node and run the container there.

8. Networking and connectivity

8.1 Public and private-style connectivity

A component may require:

Public HTTP or HTTPS access.
Public TCP access on a supported port.
Access restricted by IP allowlist.
Connectivity only from components on same resource group/Node.
Cloudflare edge proxying.
Forward authentication using Seemi’s forward-auth service.
No public endpoint.

The available options depend on the product and platform configuration.

8.2 HTTP and HTTPS services

Supported web services can be published through managed ingress. The platform provides:

Domain routing.
TLS certificate issuance and renewal.
HTTPS termination.
Routing to the component’s internal port.
Optional forward authentication.
Optional Cloudflare-related edge features where enabled.

TLS normally terminates at the reverse proxy. Internal traffic between the proxy and workload may not always use TLS. Applications requiring end-to-end encryption must implement it at application level unless the SKU expressly provides it. Certain SKUs(i.e MySQL) donot cleanly support TLS Termination at proxy hence different arrangements are used for such SKUs. Customers should review the applicable SKU documentation for details.

8.3 TCP services

Databases, caches, message brokers, SFTP services, and other TCP workloads may use supported exposed ports.

Customers are responsible for:

Enabling only required ports.
Applying IP allowlists where available.
Using strong service credentials.
Enabling application-level TLS where required.
Avoiding public exposure when internal connectivity is sufficient.
Rotating credentials after suspected disclosure.

8.4 IP allowlists and firewall rules

An IP allowlist limits access to approved source addresses or networks. It is useful for:

Administrative database access.
Office or VPN egress addresses.
Known application servers.
Integration partners with fixed addresses.

An allowlist does not replace application authentication. Source addresses can change, and a trusted network can still contain a compromised device.

8.5 Resource-group and node connectivity

Typically components in the same resource group and node can communicate without exposing a service to the public internet. Container’s use internal DNS labels that match their public FQDNs. That being said, it is better to design services that they donot have to rely on being provisioned on same node as sister components in the resource group. Node selection is guided by various inputs, most importantly the available capacity within the node. A migration to another node(triggered manually or automatically) can change assumptions tied to local placement.

8.6 Domains and DNS

Whenever a container component with WAN access is provisioned, the platform automatically provides an access URL, and sets up the records needed to enable acces to the component from this URL. Customer’s can request for a container to be accessible from a custom URL(on their own domain), in such cases Customers remain responsible for setting up the DNS records for their domain. This allows the components to be accessble from custom domains while letting Seemi acquire TLS certificates needed.

When setting up a custom domain:

Use the exact record name, value and record type provided by Seemi Cloud.
Avoid deleting old records until the component is deleted/mapping is no longe rneeded..
Allow for DNS caching and propagation and verify on Container configuruation page if the platform can validate presence of mandatory DNS Records.

8.7 Cloudflare edge options

Compatible HTTP applications may use Cloudflare proxying or related features when supported and enabled. Potential benefits include:

Edge caching.
Additional DDoS mitigation.
Request filtering.
Access controls.
Reduced direct exposure of origin addresses.

Cloudflare processing may involve web traffic, IP addresses, request metadata, and cached content depending on configuration. Review the applicable privacy and data-processing terms before enabling it.

8.8 Egress and fair use

Container network transfer may be subject to fair-use expectations even where there is no separately itemised egress fee. Object storage has its own included transfer allowance and overage model.

Customers must not use Seemi Cloud for public proxies, anonymisation relays, mass scanning, abusive traffic, or other operations that donot fall inline with our terms of service.

9. Identity and access management

9.1 Human authentication

Seemi Cloud uses supported third-party identity providers, currently this includes Microsoft and Google. Seemi does not need to maintain a separate password for the platform when using federated authentication.

Customers should:

Enable multifactor authentication at the identity provider.
Protect recovery methods.
Remove departed users promptly.
Review tenant and resource-group access regularly.
Avoid shared user accounts.
Use least privilege.

9.2 Access levels

Seemi Cloud may expose L1, L2, and L3 access levels. These labels represent increasing or distinct operational permissions according to the current permission matrix.

The permission matrix exposed through the portal or documentation is authoritative. Depending on scope and level, a user may be able to:

View resources.
View usage or operational information.
Start or stop components.
Modify configuration.
Run backups or restores.
Create billable resources.
Delete components.
Manage users or permissions.

9.3 Scope hierarchy

Permissions may be assigned at:

Tenant level.
Resource-group level.
Component level, where supported.

A broader scope can affect more resources. Prefer the narrowest scope that supports the user’s responsibilities.

9.4 Service principals

A service principal is a non-human identity intended for automation. Service principals can be used by:

Deployment pipelines.
Administration scripts.
Monitoring tools.
Internal platforms.
AI agents.
MCP clients.

A service principal should have:

The minimum required permissions.
A limited scope.
Securely stored credentials.
A rotation and revocation plan.

Do not place service-principal credentials in public repositories, browser code, screenshots, chat messages, or unprotected logs. Seemi restricts certain high risk operations to human users such are registration of payment methods, executing on session payments, creating tenants or accepting legal terms.

9.5 JWT and API authentication

The platform exposes various APIs, to access any API, a signed JSON Web Tokens is required. Shortlived tokens need to be obtained and used for API Calls. During the API Call, the platform validates the access available to the service principal before the operation is permitted.

For MCP Tools, the platform accepts the service principal secret key directly for tool calls, this supports various AI Agents that currently donot cleanly support JWT Token reissuance.

10. Secrets and credentials

10.1 Types of secrets

Workloads may require:

Database passwords.
API keys.
OAuth client secrets.
Registry credentials.
Storage access keys.
TLS private keys.
Model-provider keys.
Service-principal credentials.

10.2 Secret handling

Customers should:

Store secrets only in the environment variable fields provided in container configuration or in external secret management systems.
Avoid embedding secrets in images or source code.
Rotate secrets periodically and after suspected disclosure.
Use separate secrets by application/environment.

10.3 Support interactions

Do not send passwords, access keys, API tokens, private keys, or production secrets through the public chat or email. Seemi’s support team will not request secrets via any of these channels.

If support requires advanced access, Seemi can request component access via the standard access request method. Customers should rotate temporary credentials after the support activity concludes.

11. Custom containers and images

11.1 Public and private images

A custom container can be deployed from a supported registry. Public images can be retrieved without private credentials. Private registries require customers to share the image with seemi’s service accounts on that registry.

The customer is responsible for ensuring that:

The image is lawfully licensed.
The registry remains available.
The selected tag or digest exists.
The image supports the target architecture.
The image starts correctly with the configured entry point.
Required ports and volumes are configured.
Image vulnerabilities are addressed.

11.2 Tags and digests

A mutable tag such as latest can point to different image content over time. For predictable production deployments, prefer a versioned tag or immutable digest. The container ‘Recreate’ option allows customers to peek into the image digest used for a running container and that available in the registry. Customers can use the recreate feature to update the container image without deletion of underlying volumes/configurations. Using same tag across images where application handles volume content different can lead to unexpected behaviour.

11.3 SKU configuration

A custom container requires following inputs whe creating the SKU:

Image Registry/Repo/Version
Exposed ports.
Persistent volumes.
Command or entry-point settings.
Health checks.
Resource limits.
Domain and ingress settings.

Test the image locally or in a non-production resource group before production use.

11.4 Unsupported capabilities

Following capabilities are not allowed in container deployments to respect platform security model:

Privileged mode.
Host networking.
Host process or IPC namespaces.
Docker or container-runtime socket access.
Arbitrary host-path mounts.
Kernel module manipulation.
Nested virtualisation.

11.5 Health and restart behaviour

A process that exits may be restarted according to the service configuration. Restart behaviour does not guarantee application health.

Applications should:

Expose meaningful health endpoints where supported.
Fail clearly when required dependencies are unavailable.
Handle termination signals.
Flush or persist data appropriately.
Avoid storing important data only in the ephemeral container layer.

12. Persistent storage

12.1 Ephemeral and persistent data

The container filesystem may contain ephemeral data that can be lost when a component is recreated. Important data should be stored on an assigned persistent volume, database storage, or S3-compatible object storage as appropriate.

Typical persistent data includes:

Database files.
Uploaded content.
Application state.
Workspace files.
Message-broker state.
Configuration that cannot be recreated automatically.

12.2 Volume sizing

When estimating size of disk needed for a volume, allow room for:

Current data.
Indexes.
Temporary operations.
Logs.
Updates and migrations.
Database maintenance.
Backup staging where applicable.
Expected growth.

Disk space allowed within SKU configuration is a soft limit and higher disk usage will lead to overage being billed.

12.3 Resizing

With soft limits on persistant storage, containers are not stopped when they hit storage limits. However if the container hits node’s available diskspace, then support team can help customers backup/migrate the application to an alternative node or provision additional disk space on the node.

13. S3-compatible object storage

13.1 Service model

Seemi Cloud provides S3-compatible object storage using managed object-storage infrastructure. Object data is stored in buckets and accessed using S3-compatible endpoints, access keys, supported SDKs, command-line tools, backup applications, or the Seemi Cloud storage console.

Object storage uses a flat object model rather than a conventional filesystem hierarchy. Applications commonly present object keys containing / characters as folders, but these folders are logical prefixes rather than physical directories.

Customers can use the service for workloads such as:

Application files and uploaded content.
Container and database backups.
Logs and audit archives.
Static assets.
Data-lake files.
Media and document storage.
Software packages and build artefacts.
Disaster-recovery copies.
Long-term data retention.

S3 compatibility does not mean that every Amazon S3 service, storage class, API, authentication mechanism, event destination, or management feature is supported. Customers should test application compatibility before using the service for production workloads.

13.2 Buckets, objects, and regions

A bucket is a logical container for objects. Each bucket is created in a selected storage region and is accessed through the endpoint associated with that region.

Each stored object normally has:

A bucket name.
An object key.
Object content.
A content type.
A size.
A modification timestamp.
System and user-defined metadata.
An access state.
A version identifier where versioning is enabled.
Integrity information such as a checksum or entity tag where supported.

Bucket names and object keys should not contain secrets, personal information, or other information that should not appear in URLs, logs, usage records, or operational tooling.

A bucket’s region cannot normally be changed in place. Moving data to another region generally requires creating another bucket and copying or replicating the objects.

Customers should choose a storage region based on:

Application latency.
Data-residency requirements.
Proximity to compute workloads.
Backup-separation requirements.
Disaster-recovery design.
Integration compatibility.
Regional availability.

Compute and object-storage regions are separate selections. A container running in one compute region may use object storage located in another region.

13.3 S3 API compatibility

The service supports commonly used Amazon S3-compatible operations, including operations for:

Creating and listing buckets.
Uploading, downloading, copying, listing, and deleting objects.
Multipart uploads.
Object metadata and tags.
Bucket and object access controls.
Bucket versioning.
Bucket encryption.
CORS configuration.
Object Lock and retention.
Legal holds.
Lifecycle expiration.
Presigned access where supported by the client and API operation.
Audit logging.
Replication where enabled.

Applications must use the endpoint, access-key identifier, secret access key, signing method, and addressing style supported for the selected region.

S3-compatible tools may require configuration changes such as:

Providing a custom endpoint URL.
Selecting AWS Signature Version 4.
Enabling path-style or virtual-host-style addressing as appropriate.
Selecting a compatible region value.
Disabling unsupported Amazon-specific functionality.
Adjusting multipart-upload thresholds.
Configuring certificate and TLS validation correctly.

Customers should verify compatibility in a non-production environment, particularly where software depends on AWS-specific identity services, storage classes, inventory reports, analytics, access points, Lambda integrations, or other services outside the core S3 object API.

13.4 Access keys and permissions

S3 access is authenticated using an access-key identifier and secret access key. Access keys are high-value credentials and must be protected in the same manner as passwords or API secrets.

Customers should use separate credentials for separate applications and environments and grant only the permissions required by each workload.

Where a workload only needs to upload objects, an upload-only credential should be preferred over a credential that can read or delete existing data.

Access keys must not be placed in browser code, public repositories, container images, screenshots, support messages, or unprotected logs.

Access-key restrictions protect access to the storage API. They do not replace application-level authorization where multiple end users access objects through the same application.

13.5 Encryption

Connections to S3-compatible endpoints use TLS to protect data while it is transferred over the network.

Customers can enable server-side encryption for eligible buckets through the Seemi Cloud storage console by opening the applicable bucket settings.

Server-side encryption protects stored object data but does not prevent an authorized identity from retrieving an object through the normal API. Access controls and credential security remain necessary.

For highly sensitive data, customers should consider encrypting content before uploading it. Customers using customer-side encryption remain responsible for securely retaining the encryption keys. Loss of an encryption key may make the stored data permanently unrecoverable.

13.6 Versioning

Bucket versioning retains previous versions when an object is overwritten or deleted. It can help customers recover from accidental modification, application errors, and some forms of malicious activity.

When versioning is enabled:

Uploading an object under an existing key creates a new version.
Previous versions continue to consume storage.
Deleting an object may create a delete marker rather than immediately removing every stored version.
Permanently deleting data may require deletion of all versions and delete markers.
Replication and lifecycle behaviour may differ between current and non-current versions.

Versioning is not a complete backup strategy. An identity with sufficient permissions may be able to delete previous versions. Compromised credentials may also permit destructive operations unless additional controls such as Object Lock, retention, MFA-protected deletion, or independent backup copies are used.

Customers should configure lifecycle rules where appropriate so that obsolete versions do not grow without control.

13.7 Object Lock, retention, and legal holds

Eligible buckets support S3-compatible Object Lock. Object Lock can make selected object versions immutable for a defined period or until an applicable legal hold is removed.

Retention modes may provide different levels of protection. Some retention settings can be overridden by specially authorized identities, while stronger compliance retention may prevent deletion until the specified retention period expires.

A legal hold can prevent modification or deletion until the hold is explicitly removed.

Object Lock should be configured carefully. Incorrect retention settings may prevent Seemi Cloud, the customer, or the underlying storage provider from deleting retained objects until the applicable retention condition expires or is removed.

Customers must validate that retention settings match their legal and operational requirements before applying them to production data.

13.8 Lifecycle management

Eligible buckets support lifecycle rules that can automatically remove objects, previous object versions, or expired delete markers after a configured period.

Lifecycle rules can be used to:

Remove temporary objects.
Delete obsolete backup files.
Remove previous object versions after a defined period.
Remove expired delete markers.
Apply different expiration periods to objects matching a key prefix.

Lifecycle expiration is destructive. Customers should test lifecycle rules using non-critical data before applying them broadly.

Lifecycle rules do not necessarily override Object Lock, retention, or legal holds. Protected objects may remain stored and billable until the applicable protection expires or is removed.

13.9 Multipart uploads and data integrity

Large objects are commonly transferred using multipart upload. Multipart upload divides an object into independently uploaded parts and completes the object after all required parts have been received.

Applications should abort failed or abandoned multipart-upload sessions where supported. Incomplete multipart uploads may retain uploaded parts and continue to consume billable storage until removed.

Applications handling important data should:

Check the result of every upload operation.
Confirm the final object size.
Validate supported checksum values where appropriate.
Verify that multipart uploads completed successfully.
Periodically test retrieval of important objects.

An entity tag should not always be treated as the MD5 hash of the complete object, particularly for multipart uploads or encrypted objects.

13.10 CORS and browser access

Eligible buckets support Cross-Origin Resource Sharing, or CORS, rules. CORS controls whether browser-based applications originating from specified domains can submit supported cross-origin requests to a bucket.

CORS is a browser security control. It is not an authentication or authorization mechanism and does not make a private object accessible by itself.

Do not configure unrestricted origins, methods, and headers unless public cross-origin access is an intentional requirement.

Browser applications should normally use an authenticated application backend or appropriately restricted temporary access rather than embedding permanent S3 access keys in frontend code.

13.11 Audit logging

Eligible buckets support audit logging that records requests made against the bucket.

Audit logs may include information about:

The requested operation.
The affected bucket or object.
The request time.
The request result.
The requesting identity or access key.
Available source information.

Audit logs may be delivered periodically rather than immediately and should not be treated as a synchronous event stream.

Audit logs consume storage and may require lifecycle rules to control long-term growth. Where audit records are important, access to modify or delete them should be restricted.

Application logs, Seemi Cloud audit records, and object-storage audit logs serve different purposes and may need to be retained independently.

13.12 Replication

Eligible storage configurations support object replication between source and destination buckets, including buckets located in different storage regions.

Replication can support:

Geographic redundancy.
Disaster-recovery preparation.
Data-localization requirements.
Lower-latency access from another region.
Maintaining an operational copy of selected objects.

Replication is not necessarily instantaneous and should not be treated as synchronous multi-region storage.

Before enabling replication, customers should understand:

Which buckets, objects, and key prefixes are replicated.
Whether existing objects are included.
Whether replication applies only to newly uploaded objects.
Whether previous versions are replicated.
Whether deletion operations or delete markers are replicated.
Whether Object Lock and retention metadata are preserved.
How replication failures are detected.
The storage charges associated with both copies.

Replication is not automatically an independent backup. Application errors, malicious actions, unwanted overwrites, or deletions may be propagated depending on the replication configuration.

13.13 Durability, availability, and recovery

The underlying storage platform distributes object data across multiple storage devices and systems and uses redundancy mechanisms such as erasure coding.

This durability design reduces the probability of losing stored objects because of hardware failure. It does not guarantee:

Continuous service availability.
Protection from customer deletion.
Protection from compromised credentials.
Protection from incorrect lifecycle rules.
Recovery from application-level corruption.
Successful restoration of a complete application.
Compliance with every regulatory retention requirement.

Object-storage durability, service availability, backup retention, and application recoverability are separate concepts.

Customers should maintain independent copies of irreplaceable data, especially where:

The data is business critical.
The storage account contains the only copy.
Regulatory retention applies.
Provider-wide incidents must be considered.
Credentials with deletion permissions are used.
A customer-controlled recovery path is required.

13.14 Storage limits and application design

The underlying provider does not impose a practical bucket-size or object-count limit for ordinary customer use. Applications remain subject to platform safeguards, account limits, API behaviour, network capacity, and acceptable-use requirements.

For large datasets, customers should consider:

Object-count growth.
Object-key design.
List-operation performance.
Multipart-upload configuration.
Concurrency limits.
Retry and backoff behaviour.
Lifecycle cleanup.
Versioning growth.
Replication overhead.
Restore and migration duration.
Application-level indexing.

Object storage is not a direct replacement for a block device, database volume, or low-latency shared filesystem. Applications that frequently modify small portions of large files may need to rewrite entire objects or use another storage model.

13.15 Deletion behaviour

Deletion behaviour depends on the bucket configuration.

For an unversioned bucket, deleting or overwriting an object may permanently remove the previous object.

For a versioned bucket:

A normal delete may create a delete marker.
Previous object versions may remain stored and billable.
Permanent deletion may require removing every version and delete marker.

Objects protected by Object Lock, retention, or legal hold cannot be permanently deleted until the applicable protection allows deletion.

Deleting an S3 storage component through Seemi Cloud may permanently remove its buckets, objects, versions, access keys, and configuration.

Customers must export required data and verify independent backups before requesting deletion. Deletion of an S3 storage component is irreversible once completed.

13.16 Pricing and data transfer

Seemi Cloud object-storage billing is governed by the pricing displayed in the portal, estimator, applicable SKU, and invoice.

Billable storage may include:

Current objects.
Previous object versions.
Replicated copies.
Retention-protected objects.
Audit logs.
Incomplete multipart uploads.

Storage usage is calculated according to the applicable pricing schedule. Where an included egress allowance is provided, transfer beyond that allowance is billable at the published overage rate.

Deleting an object does not necessarily eliminate all related storage usage where versions, replicas, retention-protected copies, audit logs, or incomplete multipart uploads remain.

Customers should monitor actual storage and transfer usage rather than relying only on the nominal size of current objects.

13.17 Recommended production configuration

For important production data:

Select an appropriate storage region.
Keep buckets private by default.
Create separate access keys for each application and environment.
Grant the minimum required bucket and operation permissions.
Enable server-side encryption.
Enable versioning where recovery from overwrites is required.
Configure lifecycle rules for obsolete versions and incomplete multipart uploads.
Use Object Lock where immutability is required.
Protect administrative accounts with multifactor authentication.
Enable audit logging for sensitive buckets.
Monitor storage usage, egress, replication, and failed operations.
Test object retrieval and application restoration.
Maintain an independent copy of irreplaceable data.

14. Backups and recovery

14.1 Backup approaches

Seemi Cloud may use different backup methods by product:

Restic snapshots for eligible filesystem volumes.
pgBackRest and continuous WAL archiving for eligible PostgreSQL services.
MySQL-specific backup tooling for eligible MySQL services.
S3-compatible object storage as a backup destination.
Other service-specific methods documented for a SKU.

The presence of a backup option does not mean every product uses the same recovery model.

14.2 Filesystem and application-consistent backups

A filesystem-level backup copies files or blocks from a volume. If an application is actively writing, the backup may capture files at slightly different logical moments.

An application-consistent backup coordinates with the application or database so that the resulting recovery point is logically valid according to that product’s backup mechanism.

For some filesystem workloads, briefly pausing a container during a Restic snapshot can improve consistency. Pausing is not equivalent to a database-native backup for every transactional system. For this reason, we recommond customers to use Seemi’s platform managed Database SKUs like Postgres/MySQL to achieve consistent backups without container downtimes.

14.3 Backup schedules

A backup configuration for a container defines:

Frequency/Specific Time windows.
Covered volumes or paths.
Pause behaviour.

14.4 Recovery points

A recovery point represents a usable snapshot, backup, or point-in-time position.

Backup jobs can fail because of:

Application errors.
Application modifying volume files while backup is in progress.
Network interruption.
Credential changes.
Corruption.
Provider outage.
Misconfiguration.

Customers can Monitor backup status in the Backup Events page on the portal.

14.5 Point-in-time recovery

Eligible PostgreSQL services may support point-in-time recovery through base backups and archived WAL. A requested recovery time is translated into the nearest recoverable database state supported by the available backup chain.

Point-in-time recovery does not guarantee that every requested instant is available or that the specified target time will certainly be achieved. Should a PITR fail, customers can initiate a restore to a different snapshot held by the platform.

14.6 Restores

A restore can:

Restore a volume.
Restore a database to a selected point.
Require downtime.
Require configuration checks before traffic resumes.

After restoration, validate:

Application startup.
Data integrity.
Authentication.
External integrations.
DNS or endpoints.
Background tasks.
Replication or queues.
Application version compatibility.

14.7 Backup regions

The default S3 backup location may differ from the compute region. This placement is be disclosed on the datacentres page.

Customers with strict residency requirements should verify both active-data and backup-data locations.

14.8 Independent customer copies

Seemi-managed backups reduce risk but do not replace customer risk management. Maintain independent copies for critical data, especially when:

The workload is business critical.
Data cannot be recreated.
Long retention is required.
Regulatory obligations apply.
Recovery from a provider-wide incident must be considered.

14.9 Recovery objectives

A recovery point objective, or RPO, describes the maximum acceptable data-loss window. A recovery time objective, or RTO, describes the target time to restore service.

Do not assume an RPO or RTO unless the applicable SKU or written agreement expressly provides one. Ensure that your backup configuration respects the recovery objectives.

15. Security model

15.1 Shared responsibility

Seemi protects the platform and infrastructure within Seemi’s operational control. Customers protect their applications, data, identities, workloads, and configurations.

Seemi responsibilities may include:

Control-plane security.
Host and orchestration administration.
Tenant authorization controls.
Platform monitoring.
Infrastructure maintenance.
Included backup operation.
Operational incident response.

Customer responsibilities include:

Application code and dependencies.
Container images.
Service credentials.
User permissions.
Public exposure.
Application authentication and authorization.
Data legality and classification.
Regulatory suitability.
Independent backups.
Secure application configuration.

15.2 Defence in depth

Seemi Cloud uses multiple security layers rather than relying on one control. Layers include:

Federated identity.
Role and scope authorization.
Restricted container privileges.
Network controls.
Managed TLS.
Edge protection options.
Host patching.
Logging and monitoring.
Backup separation.
Human review of high-impact abuse or legal requests.

15.3 Vulnerability management

Seemi maintains platform vulnerability-management processes for systems under Seemi’s control. Customers remain responsible for custom images and application dependencies unless a managed service expressly includes update responsibility.

Authorized custom images may be scanned using supported tools such as Trivy. A scan is a point-in-time assessment and may not detect every vulnerability, secret, malware sample, or configuration issue.

16. Billing and usage

16.1 Billing model

Seemi Cloud uses the SKU, resource allocation, region, quantity, usage, and lifecycle records to calculate charges.

Unless a SKU states otherwise:

Usage is billed with daily minimum granularity.
A stopped component may remain billable unless undeployed or deleted.
Billing stops only after successful deletion of chargeable active resources.
Retained backups or storage may continue to incur charges post undeployment.
Object storage is billed by actual usage beyond the allowed limit.

16.2 Pricing estimator

The estimator helps customers model a configuration before deployment. It can include:

SKU category.
SKU tier.
Region.
Quantity.
Custom-container vCPU and RAM.
Additional SSD.
Additional backup capacity.
Object-storage use.
Object-storage egress.

The estimator is not an invoice. Final charges depend on the provisioned configuration and actual usage.

16.3 Regional pricing

Regional multipliers may affect compute pricing. The selected region can change the estimate even when the resource configuration remains the same.

16.4 Invoices and statements

Customers may be able to review:

Daily usage lines.
Component identifiers.
Billing dates.
Prices and currency.
Credits and discounts.
Monthly invoice totals.
Payment status.

Raise billing questions promptly and identify the disputed component, date, and line item.

16.5 Payment methods

Payment collection may use Stripe-hosted interfaces. Seemi does not need to store full card numbers when using hosted payment collection.

Customers are responsible for maintaining a valid payment method where required and for keeping billing contacts current.

16.6 Taxes and currency

The portal or invoice identifies the billing currency and applicable tax treatment. Taxes may change when legal or registration requirements change.

17. Support and professional services

17.1 Standard support

Standard support assists with Seemi Cloud platform operation within the applicable support scope. Requests can be sent to cloud.support@seemi.net.

Examples include:

Provisioning failure.
Portal operation errors.
Backup/Restore assistance beyond functions availble on portal.
Billing questions.
Suspected platform incidents.

17.2 Customer application support

Application debugging, custom code changes, architecture evaluation & consulting, migration work, and architecture design may fall outside standard support.

Seemi offers professional services for:

Migration.
Data engineering.
Application deployment.
Smartstore implementation.
Dashboard development.
Database design.
Integration engineering.
Custom enterprise infrastructure.

17.3 Responsible support requests

When contacting support:

Use the tenant’s authorized contact.
Provide specific identifiers(Tenant ID, ResourceGroup ID).
Describe impact and urgency accurately.
Donot submit secrets through email or chat.
Cooperate with diagnostic steps.

18. Recommended deployment workflow

A disciplined deployment workflow is:

Choose SKU: Identify SKU and create draft..
Choose the region: Balance capacity availability, residency, distance to intended resource customers.
Define Configuration: Setup Neworking rules, Environment variables, other details on the configuration page.
Configure backups: Select schedule for backups and whether container should run during this time..
Deploy: Deploy Container and wait for deployment tasks to complete..
Monitor resource use: Confirm CPU, RAM, disk, logs, and application performance.
Test restoration: Run a backup and then a restore process to Verify that the backup can produce a usable workload.
Review regularly: Reassess permissions, costs, capacity, vulnerabilities, and backups.

19. Production readiness checklist

Before treating a component as production ready, confirm:

The SKU has enough CPU, RAM, and disk headroom.
The selected region is appropriate.
Application and administrative endpoints are protected.
Application has strong means of authentication, determin if Seemi Forward auth would be required.
Service principals have minimum required access.
Secrets are not embedded in source code or images.
Persistent data is stored outside the ephemeral container layer.
Backups are configured and monitored.
A restore has been tested.
Independent copies exist for critical data.
Application Logs avoid secrets and unnecessary personal data.
The workload complies with the Terms of Service and applicable law.

28. Glossary

API

An application programming interface used by software to interact with supported Seemi Cloud functionality.

Backup

A separately retained copy or recovery representation of eligible data created using a supported backup method.

Component

A deployed or managed resource such as a container, database, application, volume, or storage service.

Compute node

An underlying server or node on which one or more eligible components run.

Control plane

The platform systems responsible for administration, orchestration, access control, metering, and resource lifecycle management.

Customer content

Applications, data, files, objects, images, secrets, configurations, logs, prompts, outputs, and other information supplied, stored, transmitted, or generated by or for the customer through the services.

Data centre region

A geographic location used for compute, storage, or backup services.

Egress

Data transferred out of a service or provider boundary according to the applicable pricing and measurement rules.

FE

A StarRocks frontend role responsible for metadata, client connections, query planning, and scheduling.

CN

A StarRocks compute-node role used for query execution in a shared-data deployment.

MCP

Model Context Protocol, a standard through which compatible AI clients can discover and invoke tools exposed by an MCP server.

Point-in-time recovery

A database recovery capability that restores to an available position near a requested time using a valid backup and transaction-log sequence.

Resource group

A logical grouping of components and an access-control boundary within a tenant.

Restic

Backup software used for eligible encrypted, incremental filesystem snapshots.

RPO

Recovery point objective, describing the acceptable data-loss window.

RTO

Recovery time objective, describing the target time to restore service.

S3-compatible storage

Object storage supporting identified APIs and behaviours commonly associated with Amazon S3, without implying full feature equivalence.

Service principal

A non-human identity used by applications, scripts, CI/CD systems, AI agents, and other automation.

SKU

A published product configuration or billing unit with defined resources, behaviour, limitations, and pricing.

Tenant

The primary administration, contractual, access, and billing boundary in Seemi Cloud.

vCPU

A virtual CPU allocation used for compute sizing and billing.

WAL

Write-ahead log, used by PostgreSQL to record database changes and support crash recovery and eligible point-in-time recovery workflows.

For questions that are not answered in the documentation, contact cloud.support@seemi.net.