Seemi Cloud SKU Documentation

1. How to use this documentation

This document describes the purpose, operating model, connectivity, security, persistence, backup, recovery, risks, and customer responsibilities for Seemi Cloud product SKUs.

Exact SKU names, included CPU, memory, SSD capacity, backup allocation, regional availability, and current prices are maintained on the Pricing and Estimator page and in the Seemi Cloud portal. The public catalogue is available at View and deploy SKUs.

The documentation focuses on what each product does and how customers can use it safely and effectively. It does not replace the configuration displayed before provisioning, the Seemi Cloud Services Agreement, or a signed enterprise agreement.

1.1 Common platform capabilities

Unless a product section states otherwise, Seemi Cloud services can benefit from the following platform capabilities:

• Deployment into supported compute regions.
• Tenant and resource-group authorization boundaries.
• Public or restricted network exposure according to the protocol.
• IP allowlists for supported TCP services.
• Managed domains and TLS for supported HTTP applications.
• Forward authentication for eligible browser applications.
• Optional Cloudflare proxying for eligible HTTP applications.
• Persistent SSD storage where required.
• Scheduled Restic backups for eligible files and volumes.
• Product-specific database backup tooling where documented.
• Portal-driven provisioning, lifecycle, backup, and restore operations.
• Logs and operational status through supported portal views.
• Enterprise migration, implementation, and architecture support.

1.4 Port and TLS terminology

A product may have an internal container port, an externally published TCP endpoint, or an HTTP endpoint routed through managed ingress.

• HTTP applications normally use reverse-proxy TLS termination. Traffic from the customer to the public endpoint is encrypted. Traffic inside the trusted workload boundary may not use end-to-end TLS unless there is an application level encryption setup. For certain HTTP applications forward authentication can be configured to present sign in screen utilizing seemi Microsoft/google SSO for additional security.
• Native TCP protocols such as PostgreSQL, MySQL, Redis, AMQP, SFTP, and the StarRocks MySQL protocol do not use ordinary HTTP forward authentication or Cloudflare orange-proxy mode.

1.5 Backup terminology

• Restic backup means an encrypted, incremental snapshot of eligible files or volumes into Seemi-managed S3-compatible backup storage.
• Application-consistent backup uses product-aware tooling, such as pgBackRest or XtraBackup, to coordinate with the database.
• Filesystem-consistent backup protects volume contents. Seemi may pause an eligible container during the snapshot, but pausing is not equivalent to a native database backup for every product.
• PITR means point-in-time recovery and is available only where expressly documented.

Backups reduce risk but do not remove the need for independent customer copies and restore testing.

2. Custom Container Hosting

2.1 Purpose

The Custom Container SKU runs customer-provided OCI-compatible container images. It is suitable for teams that want to deploy software without managing virtual machines, operating-system patching, Docker hosts, reverse proxies, certificate issuance, manage backup/restore workflows and routine infrastructure orchestration.

Typical workloads include:

• Web applications and APIs.
• Background workers and schedulers.
• Internal business tools.
• Automation services.
• AI and agentic applications.
• Open-source products not yet present in the managed catalogue.
• Development and testing environments.

Seemi manages the platform and deployment lifecycle, while the customer remains responsible for the image, application code, dependencies, licenses, configuration, and application-level security.

2.2 Image sources

Customers can deploy a public image from a compatible registry or grant the Seemi service account access to a private image.

Seemi’s service-account names are:

• GitHub Container Registry: seemi-service
• GitLab: seemi-service
• Docker Hub: seemiservice

The portal can provide an access test so the customer can verify that Seemi can retrieve the private image before provisioning. Seemi enfroces reasonable guradrails to ensure security of customer datasets including images. Refer to our privacy policy for additional details.

For reliable production releases:

• Prefer immutable image digests or versioned tags.
• Avoid relying on a mutable tag, specially when container image is not fully backward compatible with pre-existing persisted volumes.
• Use a minimal trusted base image.
• Run as a non-root user where the application supports it.
• Remove build tools and credentials from the final layer.
• Keep an independent copy of source code and build instructions.

2.3 Resources

Custom containers allow controlled selection of CPU and memory within public estimator limits. Public self-service limits may include up to 24 vCPU and 120 GB RAM. SSD and backup capacity can be added according to current pricing.

Larger nodes, custom specifications, and tenant-dedicated nodes may be available for enterprise customers through cloud.support@seemi.net.

2.4 Environment variables and secrets

Applications can receive secrets and other configuration variables via environment variables.

Do not:

• Bake secrets into the image.
• Commit secrets to source control.
• Print secrets into container logs.
• Pass credentials to Seemi’s support through any channels.

Rotate secrets after suspected disclosure or a support case where Seemi’s support team a and use separate values for development and production.

2.5 Ports and endpoints

The application must listen on the configured internal container port and on an interface reachable inside the container, normally 0.0.0.0. Containers

Common examples include:

• HTTP applications: internal port 80, 3000, 5000, 8000, or 8080.
• HTTPS implemented inside the application: a product-specific internal TLS port.
• Native TCP services: the port required by the application.

For browser applications, Seemi can publish a domain through managed ingress and terminate TLS at the reverse proxy. While creating the SKU, you can specify what ports the container binds to internally, select the external port number for your internal port. Wherever traffic on a specific port would not allow clean hostname based routing in reverse proxy, dyanmic port allocation is used. This means during provisioning the backplane would assign an available port from a set of dynamic TCP/UDP ports available.

2.5.1 Reverse Proxy Port Allocation

Each Seemi Cloud node runs a reverse proxy that accepts inbound traffic and routes it to the appropriate container endpoint.

Ports are classified as either:

• Static shared ports: Multiple container deployments can use the same WAN port. Reverse proxy selects the destination using HTTP hostname routing or TLS SNI routing.
• Dynamic ports: A port is allocated exclusively to a container endpoint when the underlying protocol cannot be reliably routed using a hostname. Dynamic ports can change when the container is redeployed as the ports are assigned on a first come first serve basis in every node. Port allocation algorithm tries to assign port numbers used before but this cannot be guranteed as new deployments can acquire available dyanmic ports.

2.5.2 Available Ports

2.5.3 Dynamic TCP Port Usage

Ports in the 20000-20149/TCP range are assigned exclusively to individual container endpoints.

Common examples include:

• MySQL
• StarRocks FE SQL
• SFTP and SSH
• Plain Redis
• Plain RabbitMQ AMQP
• Custom TCP services
• Bring Your Own Image containers exposing non-HTTP protocols
• TLS applications or clients that do not provide reliable SNI routing
• Compatibility endpoints for services that cannot use a shared static port

Each allocated WAN port is mapped by Proxy to the container’s internal application port. The WAN port does not need to match the internal container port.

For example:

2.5.4 Dynamic UDP Port Usage

Ports in the 20200-20349/UDP range are assigned exclusively to individual UDP endpoints.

Typical examples include:

• Approved networking service workloads
• Custom UDP services
• Bring Your Own Image containers that require UDP
• Applications that cannot share a UDP port with another deployment

UDP ports are not hostname-routed because UDP traffic does not provide HTTP host headers or standard TLS SNI information. As specified earlier, assigned dynamic ports can change during redeployment scenarios. This can happen when a container is undeployed and redployed on same or other node.

2.5.5 Static Shared Port Requirements

A container endpoint may use a shared static port only when Traefik can reliably identify the destination deployment.

This normally requires one of the following:

1. HTTP hostname routing

   The client sends an HTTP Host header, enabling multiple applications to share ports 80 and 443.

2. TLS SNI routing

   The client connects using the deployment hostname and includes that hostname in the TLS Server Name Indication handshake.

3. Supported protocol-aware routing

   Traefik explicitly understands the protocol negotiation, such as PostgreSQL STARTTLS.

If these requirements are not met, the endpoint must use a dynamically assigned TCP or UDP port and customer’s should set the port to use dynamic port numbers while configuring the SKU.

2.6 Domains, TLS, and edge protection

All Containers on Seemi Cloud Platform are assigned a unique InfraComponentID, this is a combination of Tenant, ResourceGroup and Component ID. Every container is assigned a URL built from same InfraComponentID. In addition to the provided URL, A Contained can have:

• A supported custom domain.
• Automated TLS certificate issuance and renewal.
• Optional Cloudflare orange-proxy mode for caching and additional edge-protection.
• Forward authentication for protected web applications.

Forward authentication presents a Seemi sign-in flow using supported Microsoft or Google authentication. Access is granted only to identities authorized for the relevant resource. Forward authentication protects browser access to the web interface; it does not replace authentication inside APIs, databases, or other native protocols.

2.7 Persistent storage

Data written only to the ephemeral container layer can be lost when a container is recreated. Use assigned persistent paths or external storage for important data. For modern applications, our guidance is to avoid the need for persistent volumes where possible as this allows container to be stateless, easily deployable without dependence on volume backups and their integrity. This can also allow our platform to offer higher availability with automated redeployment. From an architecture perspective, stateless container applications can also scale horizontally which is a generally preferable.

Persistent volumes are appropriate for:

• Uploaded application files.
• Stateful application directories.
• Local indexes.
• Development workspaces.
• Application configuration that cannot be recreated.

S3-compatible object storage or a database is a better choice for all persistant data, such as files, media, artifacts, logs, exports, and data that must be accessed by multiple workloads.

2.8 Backup and restore

Persistent binds and volumes can use Restic backups. The customer selects the supported schedule and retention configuration. Restic creates incremental encrypted snapshots and stores backup data in Seemi-managed S3-compatible backup storage.

If configured by user, Seemi can stop the container during backup. This reduces changes during the snapshot but can briefly interrupt service. Applications with complex transactional state should use application-native backup tooling instead of a filesystem snapshot.

A stateless container with no persistent data can often be recreated rapidly on another suitable node from its image and configuration. This improves recoverability.

2.9 Logs and terminal access

Where SKUs plan supports, portal operations include:

• Real-time or container logs.
• An interactive exec terminal for authorized users and supported plans.
• Ability to start/stop/Recreate Containers
• Ability to request backups/restores
• Ability to modify container configuration.

Terminal access is powerful. Anyone with terminal access can read/modify container’s internal files, environment variables, and mounted data. End users must grant it only to trusted users..

2.10 Image vulnerability scanning

Authorized images may be scanned periodically for known vulnerabilities. Findings can be reported to the customer for remediation.

Scanning has limitations:

• A newly published vulnerability may not appear immediately.
• A clean scan does not guarantee a secure application.
• Runtime configuration and exposed application flaws may not be detected.
• Customers remain responsible for rebuilding and redeploying custom images.
• Vulnerability databases like those used by Trivy are not necessarily upto date with every vulnerability that exists.

2.11 Deployment actions

• View pricing and build an estimate
• Review regions
• Deploy from the catalogue

3. S3-Compatible Object Storage

3.1 Purpose

S3-compatible object storage stores data as objects inside buckets and exposes compatible HTTP APIs. It is a foundational service for digital applications, backup systems, content delivery, analytics, archives, artifacts, and data lakes.

Common uses include:

• Application uploads and downloads.
• Images, video, and documents.
• Software artifacts and container-related assets.
• Database and volume backups.
• Logs and export files.
• Analytical datasets.
• StarRocks shared-data storage.
• Static content and long-lived archives.

The service is S3-compatible. It is not Amazon S3 and does not imply support for every Amazon-specific feature.

3.2 Endpoint and protocol

Applications connect to the regional HTTPS endpoint, normally using TCP port 443. Requests use S3-compatible REST operations and signed credentials.

Depending on the client being used, customers need to specify:

• Endpoint URL.
• Region code.
• Access-key ID.
• Secret-access key.

Use HTTPS and validate the endpoint certificate. Do not disable certificate validation in production.

3.3 Available regions and endpoints

Capacity can vary by region. The portal remains authoritative for current availability.

3.4 Buckets and objects

A bucket is the main object namespace. Objects are addressed by keys. Object keys can use slash-like prefixes for organization, but object storage is not a traditional filesystem.

Plan bucket structure around:

• Application ownership.
• Environment.
• Access policy.
• Retention.
• Data residency.
• Replication requirements.
• Cost allocation.

Avoid placing secrets or unnecessary personal information in bucket names and object keys because names can appear in logs and operational records.

3.5 Credentials and scoped keys

The portal storage browser can support creation and management of access credentials. Customers can use time-scoped or bucket-scoped keys where available.

Use separate keys for separate applications. A key used only for upload should not have delete or administrative permissions if those actions are unnecessary.

Rotate credentials when:

• A team member leaves.
• An application is retired.
• A key appears in source control or logs.
• A third-party integration no longer needs access.
• A security incident is suspected.

3.6 Storage browser

Seemi provides a browser-based utility for storage administration, including activities such as:

• Listing buckets and objects.
• Uploading and downloading files.
• Managing files and object metadata.
• Creating access keys.
• Reviewing storage usage/Stats.
• Configuring supported replication workflows.

End users can share the storage access by sharing component access to a different platform user.

3.8 Durability and availability

The intended durability target is eleven nines, or 99.999999999%, and the aimed service availability target is 99.9%, subject to the applicable SKU and service terms.

Durability is not the same as availability:

• Durability concerns the risk of losing stored objects.
• Availability concerns whether the service can respond at a particular time.

For higher resilience, customers should consider cross-region replication and independent copies. There have been actual cases where customers lost cloud data as a result of physical damage inflicted on datacentres in middleeast. Replication can protect against some regional failures, but incorrectly configured replication can also copy unwanted changes or deletions.

3.9 Free storage SKU

The free storage SKU provides up to 5 GB primarily for development and testing. Free SKUs are subject to availability and typically offered in specific regions. A verified saved payment method will be required within 15 days of tenant creation. Overage remains billable even when the base SKU is free.

Do not store the only copy of important production data in the free tier.

3.10 Egress and pricing

Current pricing may include egress equal to three times the stored capacity. Usage over that allowance is charged according to current pricing. API operations currently have no separate line-item charge.

Review the Pricing and Estimator page for current rates.

3.11 Replication

Cross-region replication can support:

• Regional resilience.
• Local data access.
• Disaster recovery.
• Data distribution.

Before enabling replication, consider:

• Destination-region residency.
• Additional stored data and charges.
• Replication delay.
• Version and delete-marker behaviour.
• Credential and policy scope.
• Recovery and failover procedures.

Replication is not enabled by default.

3.12 Deployment actions

• Create the free storage SKU
• View existing resources
• View pricing
• Review storage regions

4. PostgreSQL 18

4.1 Purpose

PostgreSQL is a mature relational database for transactional systems, APIs, SaaS applications, business platforms, spatial workloads, reporting, and operational data. Seemi Cloud provides first-class PostgreSQL 18 SKUs from development capacity through enterprise-scale configurations.

Seemi Technology Group is officially recognized by the PostgreSQL.org as a professional postgres hosting-provider.

4.2 Workload fit

PostgreSQL is suitable for:

• Transactional web and mobile applications.
• Business systems requiring relational integrity.
• JSON and mixed relational-document workloads.
• Equipment and manufacturing data collection.
• Geospatial applications where supported extensions are available.
• Reporting stores and application backends.
• Systems requiring point-in-time recovery.

4.3 Version and image

The standard SKU uses PostgreSQL 18 with pgBackRest integrated for backup workflows. Seemi uses a standard postgres:18 to build an image with pgbackrest and other utilities added.

4.4 Port and connectivity

PostgreSQL uses TCP port 5432 by default. The portal displays the connection guide with host URL, credentials and connection details.

Connectivity is:

• Restricted by IP allowlist, Where no whitelist is defined and WAN access is enabled we allow access from any source IPs.
• For components with no WAN access enabled, network access is Limited to components on the same node and resource group.

Cloudflare orange-proxy mode and browser forward authentication do not apply to the PostgreSQL wire protocol.

4.5 TLS

PostgreSQL supports native TLS. Seemi’s automation manages supported certificate provisioning and service configuration. Clients should validate the server certificate and use the connection mode instructed by the portal.

For connecting to the Postgres Containers, we recommend using following settings:

1. SSL Mode=Require;
2. Pooling=true;
3. GSS Encryption Mode=Disable

The connection guide on portal will show you full connection strings for various clients.

4.6 Resources and storage

PostgreSQL uses persistent SSD storage. Database performance is dependant on memory, CPU, working-set size, indexes, checkpoints, and write volume.

When selecting the SKU:

• Allow memory for shared buffers, connections, sorts, and the operating process. Do note that once a container exhauts its allowed RAM and swap thresholds, an OOM kill can cause container to restart.
• Select CPU vCores that match the target database workload.
• Monitor long transactions and table bloat.

4.7 Backup methodology

Our PostgreSQL SKUs use pgBackRest to support:

• Full backups.
• Incremental backups.
• Automated scheduled Full or incremental backups
• Continuous WAL archiving.
• Point-in-time recovery when the required backup chain and WAL files are available.

The customer can configure supported scheduled backups through the portal or request for a backup anytime. Scheduled backups are not available on Free SKUs. Backup storage is normally located in the disclosed default S3 backup region.

4.8 Point-in-time recovery

PITR restores PostgreSQL from a valid base backup and replays archived WAL to an available point near the requested time.

PITR depends on:

• A usable base backup.
• A complete WAL sequence.
• Retention that covers the requested time.

Depending on the target timestamp selected by user during PITR Restore, it is possible that the database fails to reach that target and fails on startup. In such situation the restore task will fail. Customers can then request to restore a different full/incremental snapshot. PITR does not guarantee recovery to exact timestamp and hence full/incremental backups add additional safety.

4.9 Snapshot restore

Customers may also restore an available full or incremental backup snapshot. Restoration requires downtime and the length of this downtime would depend on database size & compute limits assigned to the container.

4.10 Node failure recovery

If a compute node fails, Seemi Cloud can provision an eligible PostgreSQL component on another suitable node and restore from the latest usable PITR position or available snapshot. Transactions after the latest recoverable point can be lost.

A single PostgreSQL SKU is not automatically a synchronous HA cluster. For mission critical data, customers are recommended to host additional backups.

4.11 Logs and advanced access

Supported customers can view operational logs. Enterprise customers receive controlled container terminal access for advanced troubleshooting.

Terminal access does not replace SQL administration and is limited to admins with L3 access on the component.

4.12 Security guidance

• Use separate database roles by application.
• Avoid using a superuser for ordinary application connections.
• Restrict source IPs.
• Require TLS.
• Rotate credentials.
• Monitor failed authentication and unusual queries.
• Patch application database drivers.
• Test restoration regularly.

4.13 Deployment actions

• View PostgreSQL pricing
• Deploy PostgreSQL
• Review regions and backup locations

5. MySQL 8

5.1 Purpose

MySQL 8 is a widely supported relational database for commerce, content systems, SaaS products, web applications, and transactional backends. Seemi Cloud currently provides single-instance MySQL 8 SKUs rather than an automatic high-availability pair.

5.2 Workload fit

MySQL is suitable for:

• Mainstream web applications.
• WordPress-compatible architectures when application requirements align.
• Commerce systems.
• SaaS backends.
• Content and customer portals.
• Vendor applications designed for MySQL 8.

5.3 Port and connectivity

Internally MySQL protocol uses TCP port 3306 and would be accessible on this port from clients within same node/resource group. For WAN access, Seemi will assign a dynamic public port number to each instance of MySQL on a node. This is because MySQL does not support clean hostname based routing via reverse proxy. The assigned public endpoint is shown in the portal connection guide.

HTTP forward authentication and Cloudflare orange-proxy mode are not available for MySQL containers.

5.4 TLS

MySQL supports native connection encryption. Customers must use the database endpoint and driver settings provided for the SKU. Validate certificates rather than disabling client verification.

5.5 Persistence and sizing

MySQL data resides on persistent SSD storage. Size the selected SKU with sufficienc vcores/RAM for:

• Buffer pool and active data.
• Concurrent sessions.
• Query complexity.
• Temporary tables.
• Index maintenance.
• Application growth.
• Backup and restore overhead.

5.6 Backup methodology

Eligible MySQL SKUs use XtraBackup tooling for application-aware backup to encrypted S3-compatible storage.

This approach is designed to create MySQL-aware physical backups while the service remains available. Do note that contineous streaming backups are not available for MySQL SKU offered by Seemi.

Backup schedules can allow clients to schedule full and incremental backups. Free SKUs donot allow scheduled backups.

5.7 Restore model

A MySQL restore retrieves the selected backup data, prepares the backup as required, and restores it into the target database environment.

Unlike the PostgreSQL service described above, the current MySQL SKU does not offer Seemi-managed PITR. Recovery is therefore limited to the available completed backup points.

This difference should influence backup frequency. A system that cannot tolerate losing changes since the latest backup may require a different architecture or additional customer-managed binlog strategy approved through enterprise engineering.

5.8 Single-instance limitation

The current MySQL SKU is a single database instance. It does not include an automatic primary-replica HA pair or automatic database failover.

Backups provide recoverability, not uninterrupted availability. Enterprise replication and high-availability requirements should be discussed with Seemi engineering.

5.9 Deployment actions

• View MySQL pricing
• Deploy MySQL
• Contact engineering

6. Redis

6.1 Purpose

Redis is an in-memory data platform used to reduce latency and support responsive applications. Common patterns include:

• Application caching.
• Session storage.
• Rate limiting.
• Counters and leaderboards.
• Short-lived coordination data.
• Queues and streams.
• Frequently accessed reference data.

Redis can dramatically improve application responsiveness, but customers must design for its memory-first behaviour.

6.2 Port and connectivity

Redis commonly uses TCP port 6380 and will normally be assinged a static port number across nodes. Use the hostname and port shown in the portal connection guide.

its recommended to avoid broadly exposing redis to the public internet. Prefer:

• Same-node and resource-group connectivity where manageable.
• Strict IP allowlists.
• Strong authentication and ACLs.

Cloudflare orange-proxy mode and browser forward authentication do not apply to the Redis protocol.

6.3 Memory sizing

Redis stores active data in memory. Running out of memory can lead to rejected writes or eviction depending on policy.

Estimate the following to determine the ideal SKU vcore/Memory size:

• Raw key and value size.
• Object overhead.
• Number of keys.
• Expiry behaviour.
• Replication or persistence overhead.
• Peak working set.
• Fragmentation.

6.4 Persistence

Redis persistence can include RDB snapshots, seemi can backup the RDB snapshots on the persisted volume to its backend S3 using restic. However we recommend using Redis as a cache when possible with no reliance on persistant data.

6.5 Backup methodology

Eligible Redis volumes use encrypted incremental Restic snapshots. if configured, Seemi will stop the container during backup to improve filesystem consistency.

A volume snapshot protects the persisted Redis files available at snapshot time. It does not guarantee zero loss of in-memory changes that have not been persisted.

6.6 Restore

A restore brings back the eligible Redis persistence files and starts the service against the restored volume. However this only restores data at the time backup was initiated. All changes from that point onward are not recoverable.

6.7 Deployment actions

• View Redis pricing
• Deploy Redis

7. RabbitMQ

7.1 Purpose

RabbitMQ is a message broker for asynchronous applications. Producers publish messages, exchanges route them, queues hold them, and consumers acknowledge completed work.

Typical uses include:

• Background jobs.
• Passing data across services.
• Notifications.
• IoT event handling.
• Workload buffering.
• Retry and dead-letter workflows.

RabbitMQ helps services remain responsive during spikes and temporary downstream interruption.

7.2 Ports

Common RabbitMQ ports include:

• 5672: AMQP without native TLS.
• 5671: AMQP over TLS.
• 15672: management UI and HTTP API without native TLS.
• 15671: management UI and HTTP API over native TLS.
• 25672: inter-node Erlang distribution in clustered architectures.
• 4369: Erlang Port Mapper Daemon in clustered architectures.

Only ports required by the selected deployment should be exposed. The portal endpoint may map these through platform controls.

7.3 Management interface

The management UI provides visibility into:

• Queues and depth.
• Exchanges and bindings.
• Connections and channels.
• Consumers.
• Publish and delivery rates.
• Memory and disk alarms.
• Users, virtual hosts, and permissions.

The management UI is an HTTP application and can use managed HTTPS and forward authentication where supported. RabbitMQ credentials are still required for broker and administrative permissions unless the configured application flow states otherwise.

7.4 AMQP TLS

AMQP is a native TCP protocol. It can use RabbitMQ’s native TLS listener or a supported TCP TLS arrangement. Do not assume HTTP reverse-proxy TLS protects AMQP traffic.

Clients should validate the server certificate and use the amqps endpoint where provided.

7.5 Users and virtual hosts

Use separate RabbitMQ users and virtual hosts for applications or environments. Apply configure, write, and read permissions narrowly.

Do not use default development credentials for remote production access.

7.6 Queue durability and message safety

Message durability depends on several related settings:

• Queue durability.
• Persistent-message publishing.
• Publisher confirms.
• Consumer acknowledgements.
• Retry and dead-letter design.
• Disk availability.

A durable queue does not make transient messages persistent. A persistent message is not a guarantee against every failure without correct publisher and broker behaviour.

7.7 Persistent storage

RabbitMQ persistent state uses an assigned volume. Allow disk headroom for:

• Queue backlogs.
• Message indexes.
• Quorum or stream data where applicable.
• Logs.
• Recovery operations.

Disk alarms can block publishers to protect the broker.

7.8 Backup methodology

Eligible RabbitMQ volumes use scheduled encrypted Restic snapshots. The container may be paused during backup where stronger filesystem consistency is required.

Seemi does not use object-storage offload as the ordinary RabbitMQ durability mechanism. Backups are Restic snapshots of eligible persistent volume data.

A filesystem backup is not a substitute for correct queue durability, publisher confirmations, acknowledgements, and application-level replay design.

7.9 Restore

Restoring broker files can require the compatible RabbitMQ and Erlang versions, node naming, and configuration. The product workflow should restore the complete supported data set rather than selected queue files.

After restoration:

• Confirm broker startup.
• Check alarms.
• Verify virtual hosts and users.
• Inspect queue state.
• Confirm consumers reconnect.
• Prevent accidental duplicate business processing.

7.10 Key risks

• Unbounded queues can consume disk and memory.
• Missing acknowledgements can cause message loss or redelivery.
• Incorrect retry logic can create loops.
• Restoring old broker state can reproduce already processed messages.
• Single-node RabbitMQ is not a clustered HA service.
• Exposing the management interface or AMQP broadly increases attack surface.

7.11 Deployment actions

• View RabbitMQ pricing
• Deploy RabbitMQ

8. OpenHands

8.1 Purpose

OpenHands provides an AI software-engineering and agent workspace. An AI model can interact with a Linux sandbox, repositories, files, terminals, and development tools to perform tasks such as:

• Understanding a codebase.
• Editing and generating code.
• Running tests.
• Investigating errors.
• Preparing container applications.
• Automating repeatable development tasks.
• Supporting agentic workflows.

8.2 Model-provider responsibility

Seemi currently provides the OpenHands runtime, not bundled AI model tokens. Customers must obtain model access and credentials from a compatible model provider or operate an approved local or remote model endpoint.

OpenHands can connect to multiple providers through its model abstraction. Model capability, price, privacy, context window, tool-use reliability, and regional availability depend on the selected provider.

Customers should:

• Set provider spending limits.
• Monitor token use.
• Use a model appropriate for coding and tool use.
• Review provider data-handling terms.
• Avoid submitting secrets unnecessarily.

8.3 Web interface and ports

OpenHands is presented as an HTTP web application. Its internal ports can vary by image and release; customers use the HTTPS endpoint shown in the portal rather than exposing internal application ports directly.

Managed TLS terminates at Seemi’s web ingress for the public UI. OpenHands workspaces and agent services may use additional internal ports that should not be broadly exposed.

8.4 Forward authentication

The OpenHands web interface uses Seemi forward authentication. A visitor sees the Seemi sign-in flow and authenticates through a supported Microsoft or Google identity. Access requires authorization to the resource.

Forward authentication protects the browser entry point. Customers must still protect:

• Model API keys.
• Repository access tokens.
• SSH keys.
• Package-registry credentials.
• Secrets inside the workspace.

8.5 Workspace persistence

The OpenHands SKU includes or supports a persistent workspace volume. Store repositories and work products in the designated persistent path.

The workspace can contain highly sensitive information. Do not assume every temporary directory or agent process output is retained after recreation.

8.6 Backup methodology

Eligible OpenHands workspace volumes use encrypted incremental Restic snapshots. The container may be paused during backup to improve consistency.

Backups can protect workspace files, but third-party repositories and model-provider conversation records remain governed by their own systems.

8.7 Security model

An AI coding agent can execute commands and modify files. Treat the agent workspace as a privileged development environment.

Recommended practices:

• Use a dedicated repository credential with minimum permissions.
• Avoid production cloud credentials in the workspace.
• Review changes before merging.
• Require CI tests and code review.
• Protect branch and deployment permissions.
• Treat repository instructions and external pages as untrusted content.
• Do not allow prompt content to expand infrastructure permissions.

8.8 Resource sizing

AI-agent workloads can require substantial CPU and memory for repository indexing, builds, browsers, language servers, and concurrent tools. Model inference normally occurs through the chosen external provider and is not included in the OpenHands compute price.

8.9 Product roadmap

Future Seemi capabilities may include curated model access, token allowances, application templates, agent-assisted container image creation, and direct deployment into Seemi Cloud. Roadmap items are not current contractual commitments until released and documented.

8.10 Key risks

• Model costs are separate and can grow rapidly.
• An agent can execute destructive commands inside the workspace.
• Untrusted repository content can attempt prompt injection.
• Generated code can contain security or licensing issues.
• Secrets can appear in logs or model context.
• Workspace backups do not back up external model-provider or source-control systems.

8.11 Deployment actions

• View OpenHands pricing
• Deploy OpenHands
• Contact Seemi engineering

9. Firefox Browser Workspace

9.1 Purpose

The Firefox SKU provides a remote browser workspace for controlled web access, testing, administration, and agent-assisted workflows where a browser must run close to cloud resources.

Typical uses include:

• Browser-based administration tools.
• Testing applications from a regional environment.
• Manual verification of web flows.
• Controlled browsing of components in same Seemi Resource group/node.
• Supporting an AI or automation workflow that requires a browser.

9.2 Web access and ports

Customers access the browser through a Seemi-published HTTPS endpoint on port 443. Internal remote-desktop or web-transport ports remain behind the platform route and should not be exposed directly unless the SKU expressly states otherwise.

9.3 Authentication

The browser interface uses Seemi forward authentication. Access is tied to authorized Seemi identities.

9.4 Persistence

Workspace files can use a persistent path that is eligible in standard restic backups/restore.

9.5 Backup methodology

Eligible persistent browser workspace paths can use Restic snapshots. Backing up a browser profile can preserve cookies and active sessions, which are sensitive credentials. Restrict restore and terminal access accordingly.

9.6 Security guidance

• Do not save high-value credentials unless required.
• Sign out of critical services after use.
• Use MFA.
• Treat downloads as untrusted.
• Keep browser versions current.
• Avoid using the workspace as an unrestricted public browsing service.
• Review persistent profile risk before enabling backups.

9.7 Deployment actions

• View pricing
• Deploy Firefox

10. Smartstore

10.1 Purpose

Smartstore is a full commerce platform for B2C, B2B, and extensible marketplace scenarios. Seemi Technology Group is an official Smartstore AG partner and can provide hosting plus optional implementation engineering.

10.2 Commerce capabilities

Smartstore can support:

• Product catalogues.
• Product variants and attributes.
• Categories and merchandising.
• Customer accounts.
• Shopping cart and checkout.
• Orders and administrative workflows.
• Returns and refunds.
• Discounts and coupons.
• Content pages and blogs.
• Responsive mobile storefronts.
• Search and SEO features.
• Extensions and plugins.

Available capabilities depend on the installed Smartstore edition, version, plugins, localization, and customer configuration.

10.3 Payments

Smartstore can integrate with Stripe and other supported gateways. Payment-gateway accounts, contracts, fees, compliance, and settlement remain the customer’s responsibility.

A payment integration can support payment authorization, capture, order status, and refunds according to the plugin and gateway. Customers must test complete payment and refund workflows before production.

Do not store raw card data in Smartstore or Seemi workloads unless an expressly approved PCI DSS architecture is in place.

10.4 Returns workflow

Smartstore can support a structured return workflow. The customer must configure return reasons, eligibility, approval, receipt, refund, exchange, and customer communication according to business policy and applicable consumer law.

10.5 Identity and SSO

Customer sign-in and administrative sign-in capabilities depend on Smartstore and installed identity plugins. Seemi forward authentication can protect the administrative or entire web endpoint however most deployment require a public storefront and rely on SmartStore’s own registration/login process..

10.6 Google Merchant Center

Supported integrations can make catalogue data available to Google Merchant Center. Product identifiers, availability, pricing, shipping, and return information must be accurate. Merchant policies and account approval remain controlled by Google and the customer.

10.7 Ports, domains, and TLS

Smartstore is an HTTP application. The container’s internal application port is routed through Seemi managed ingress. Customers use HTTPS on port 443 with a Seemi-provided or custom domain.

Optional Cloudflare proxying can provide caching and additional edge protection for compatible traffic.

10.8 Database dependency

Smartstore requires a supported relational database according such as PostgreSQL. The database is be provisioned as a separate component and charged seperately.

10.9 Persistent data

Persistent data can include:

• Uploaded product images.
• Theme and plugin files.
• Application keys.
• Generated assets.
• Logs required for troubleshooting.
• Database content in the separate database component.

10.10 Backup methodology

Our reference design for SmartStore SKU protects both parts of the system:

• Eligible Smartstore application volumes through Restic.
• Postgres uses standard pgbackrest streaming backups.

10.11 Engineering services

Seemi can offer separate paid professional services for:

• Complete store setup.
• Product Catalogue Setup.
• Payment integration.
• Merchant-centre integration.
• Custom plugin and workflow development.
• Analytics and reporting.
• Production launch support.

10.12 Deployment actions

• View pricing
• Browse the catalogue
• Discuss implementation

11. Metabase

11.1 Purpose

Metabase is a business-intelligence and analytics application for visual queries, SQL analysis, dashboards, collections, alerts, and data exploration.

Typical use cases include:

• Operational dashboards.
• Sales and finance reporting.
• Customer analytics.
• Product metrics.
• Manufacturing and supply-chain reporting.
• Internal self-service analytics.

11.2 Port and web access

Metabase listens on internal port 3000 by default. Seemi publishes the application through managed HTTPS, so users normally access it through port 443 on the assigned hostname.

11.3 TLS and forward authentication

Seemi terminates TLS at the proxy for Metabase. Forward authentication is available for Metabase and can add a Seemi Microsoft or Google sign-in gate before the Metabase interface.

Metabase’s own users, groups, permissions remain important. Forward authentication alone does not design data permissions inside Metabase.

11.4 Application database

Metabase requires an application database to store:

• Users.
• Groups and permissions.
• Questions.
• Dashboards.
• Collections.
• Alerts and subscriptions.
• Configuration.
• Metadata about connected databases.

For production, PostgreSQL is recommended. The Seemi Metabase SKU therefore requires a separate PostgreSQL component and the deployment workflow will guide to setting up Postgres aswell.

The application database is different from the customer data warehouse or operational databases/datalake that Metabase queries.

11.5 Data-source connections

Metabase can connect to supported databases using drivers and credentials. Customers should create read-only or narrowly scoped reporting users where possible.

11.6 Backups

Protect:

• The Metabase application database through standard PostgreSQL backup.
• Metabase application volume data through Restic.
• External data sources through their own backup arrangements.

Backing up the Metabase container alone does not protect the application database or the source data.

11.7 Engineering services

Seemi can offer separate services for:

• Metabase deployment.
• Data-source connection design.
• Permissions.
• Dashboard and KPI design.
• SQL modelling.
• Data warehouse and ingestion engineering.
• Migration from another BI tool.

11.8 Deployment actions

• View Metabase pricing
• Deploy Metabase
• Contact analytics engineering

12. StarRocks Shared-Data Analytics

12.1 Purpose

StarRocks is a high-performance analytical database for real-time analytics, lakehouse queries, high-concurrency dashboards, and large-scale SQL workloads.

A shared-data deployment separates compute from object storage. This can support datasets worth hundreds of terabytes while allowing compute resources to scale independently from S3 storage.

12.2 Business use cases

• Centralized enterprise data lakehouse.
• Operational analytics.
• Near-real-time reporting.
• High-concurrency BI.
• Customer-facing analytics.
• Large fact-table joins.
• Ad hoc analysis.
• Query access for AI agents.

12.3 FE and CN SKUs

Seemi publishes separate StarRocks roles:

• FE, or Frontend Engine: metadata, client connection handling, SQL parsing, planning, scheduling, and cluster coordination.
• CN, or Compute Node: execution of analytical queries, data processing, ingestion work, and local cache for hot data.

A usable cluster requires a compatible FE and CN topology plus object storage. Development can use compact configurations. Production topology should be designed for availability, query concurrency, ingestion, and metadata resilience. Typically Seemi would deploy CE/FN Containers on the same underlying node for operational simplicity.

12.4 Object storage

Seemi recommends Seemi S3-compatible storage for a straightforward integrated deployment with first class support of all components. Customers can use another compatible S3 provider assuming that the customer supplies valid endpoint, region, credentials, and bucket configuration.

The object store contains durable analytical data in a shared-data architecture. CN local disks act as cache and computation space rather than the only durable copy.

12.5 Ports

Common FE ports include:

• 9030: MySQL-compatible query port.
• 8030: FE HTTP port.
• 9020: FE RPC port.
• 9010: FE edit-log and internal coordination port.

Shared-data configurations can also use cloud-native metadata services and product-specific ports. CNs use additional heartbeat, RPC, HTTP, and internal ports according to the StarRocks version.

Only the client query endpoint and explicitly required administrative paths should be exposed. Internal cluster ports must be restricted to the cluster topology.

12.6 MySQL-compatible client interface

Users can connect to the FE query port using compatible MySQL clients and drivers. Tools such as DbGate can provide browser-based SQL access.

MySQL protocol compatibility does not make StarRocks a MySQL transactional database. SQL syntax, transaction semantics, storage model, indexes, and supported features differ.

12.7 TLS and transport

The client connection uses the StarRocks MySQL-compatible protocol, this means a dynamic port is assigned for every FE instance and TLS termination happens at the FE container.

Use the connection guide shown on the portal for exact connectin details.

12.8 Access control

StarRocks supports MySQL-style users, roles, and privileges. Granular authorization can control access to catalogs, databases, tables, views, and supported operations.

Recommended practices:

• Separate ingestion, analyst, BI, and administrative identities.
• Grant read access only to required schemas.
• Avoid using root for anything beyond administrative work/prvosioning tasks.
• Protect object-storage credentials.

12.9 Ingestion

Ingestion options can include:

• Stream Load.
• Batch loading.
• Broker or connector patterns.
• Data pipelines.
• Change-data-capture workflows.
• External catalogs and lakehouse integration.

Pipeline design must address retries, schema evolution, deduplication, late data, and monitoring.

12.10 Metadata and backup

The FE metadata is critical. We protect eligible FE metadata volumes through Restic backup workflow.

Object-storage data has its own replication model, wherver cross region replication is needed, it should be enabled at a bucket level from the S3 provider.

12.11 Scaling

Shared-data architecture can add or remove CN capacity without migrating the durable object data in the same way as a shared-nothing system. Scaling still requires attention to:

• Cache warm-up.
• Query concurrency.
• Ingestion load.
• FE planning capacity.
• Network throughput.
• Object-storage request patterns.

12.12 High availability

Production high availability can require multiple FE nodes with appropriate leader and follower roles, multiple CNs, resilient object storage, and carefully designed network placement. For advanced datalake deployments, customers should contact Seemi Engineering for a architectural guidance/recommended deployment strategy.

12.13 Enterprise engineering

Seemi can provide case-by-case support for:

• Cluster topology.
• Migration.
• Data modelling.
• Ingestion pipelines.
• BI connectivity.
• Security design.
• Multi-region architecture.
• Performance tuning.
• Disaster recovery.

12.14 Deployment actions

• View StarRocks FE and CN pricing
• Deploy StarRocks components
• Contact data engineering

13. DbGate

13.1 Purpose

DbGate is a browser-based database administration and SQL client environment. It can provide a convenient interface for supported PostgreSQL, MySQL, and MySQL-compatible endpoints such as StarRocks.

Typical uses include:

• Running SQL queries.
• Browsing schemas and tables.
• Inspecting data.
• Performing controlled administration.
• Connecting to databases without installing a desktop client.

13.2 Web access

DbGate is exposed as an HTTP web application through a managed HTTPS endpoint on port 443. The internal application port depends on the image and remains behind ingress.

13.3 Forward authentication

Seemi forward authentication can protect the DbGate UI. Only users authorized for the resource can reach the browser interface. Since Seemi allows direct communication between components on same Resource group/Node, DBgate can allow clients to manage databases without enabling WAN access, in such cases Dbgate connects to the database in same resource group using the underlying resource group docker network.

Database authentication remains separate. A user who can reach DbGate still needs valid database credentials.

13.4 Connection security

Configure each database connection using:

• The portal-provided hostname and port.
• A narrowly scoped database user.

13.5 Persistent configuration

DbGate stores connection profiles, preferences, query history, or workspace state on an eligible persistent volume. Stored connection data can be sensitive.

13.6 Backup methodology

Eligible persistent DbGate paths use encrypted Restic snapshots. These backups protect DbGate configuration, not the connected databases. Each database requires its own backup strategy.

13.7 Free SKU

A free DbGate SKU can provide lightweight development access. Free-tier limitations and payment-method requirements service terms.

13.8 Deployment actions

• View DbGate pricing
• Deploy DbGate

14. SFTPGo

14.1 Purpose

SFTPGo provides secure file-transfer services with SFTP and optional supported web, WebDAV, or object-storage-backed workflows. It can be used for:

• Partner file exchange.
• Batch imports and exports.
• Managed upload portals.
• Application integration.
• Secure delivery of reports or media.
• S3-backed file-transfer architecture.

14.2 Ports

Common ports for SFTP include:

• 22: SSH and SFTP, although public services may use another assigned port. A dynamic port will be selected and exposed for public connection using ssh/sftp.
• 8080: web administration or web client internally, depending on image configuration.
• 443: public managed HTTPS endpoint for supported web interfaces.
• 990: implicit FTPS only if explicitly configured.
• 5007: WebDAV in some SFTPGo configurations, subject to image settings.

Use only the ports shown by the portal and enabled by the SKU.

14.3 TLS and SSH security

SFTP uses SSH encryption rather than HTTP TLS. The SFTP client must validate the server host key.

Web administration and web client access can use Seemi managed HTTPS.

14.4 Users and authentication

SFTPGo can support local users, SSH keys, passwords, virtual folders, and other authentication integrations according to the installed version.

Recommended practices:

• Prefer SSH keys for automated SFTP clients.
• Use one account per partner or integration.
• Restrict users to assigned directories.
• Rotate keys and passwords.
• Disable unused accounts promptly.
• Limit source IPs where possible.

14.5 Storage architecture

SFTPGo can use local persistent storage or supported object-storage backends. We strongly recommend S3-backed design, as it separates file data from the compute container and can simplify storage growth.

Customers must understand the semantic difference between a filesystem and object storage, including rename, metadata, locking, POSIX operations, and partial-file behaviour.

14.6 Backup methodology

For local persistent SFTPGo data, eligible volumes use encrypted Restic snapshots.

For an S3-backed design, File data resides in object storage and requires its own replication, versioning, and backup strategy wherever needed.

14.7 Web interface security

The web administration interface should use managed HTTPS and forward authentication where supported. SFTP users are separate from Seemi portal users.

14.8 Deployment actions

• View SFTPGo pricing
• Deploy SFTPGo
• Discuss enterprise file transfer

15. Common operational procedures

15.1 Before provisioning

1. Confirm the product fits the workload.
2. Review the SKU resources.
3. Select a suitable region.
4. Review the default S3 backup location.
5. Identify public and internal ports.
6. Confirm backup and retention requirements.
7. Estimate cost.

15.2 After provisioning

1. Verify service health.
2. Change or confirm default credentials.
3. Apply IP allowlists.
4. Test application connectivity.
5. Configure backups and test first backup.
6. Perform a restore test before relying on the service.

15.3 Before upgrading

• Read upstream release notes.
• Confirm image and data compatibility.
• Create and verify a current backup.
• Test in a non-production component.
• Plan downtime and rollback.
• Confirm dependent clients and plugins.

15.4 Before Undeployment

• Export required data.
• Perform a backup, should you need to deploy.
• Review dependencies.
• Wait for mandatory hold period and then initiate a permanent delete if desired(permanent delete completely erases all backups)

16. Support and enterprise services

Standard platform support is available through cloud.support@seemi.net.

Enterprise and professional services can include:

• Workload assessment.
• Migration planning and execution.
• Database migration.
• Backup and recovery design.
• Smartstore implementation.
• Metabase dashboards and analytics.
• StarRocks lakehouse and ingestion engineering.
• Custom container deployment.
• Dedicated-node design.
• Security and network architecture.
• Multi-region planning.

When contacting support, include the tenant, resource group, component, approximate time, observed behaviour, and sanitized logs. Never include passwords, access keys, private keys, or model API keys in your discussions with Seemi’s support team.

17. Related resources

• Platform Concepts
• Pricing and Estimator
• Datacentres and Regions
• Security Overview
• Access and Edge Protection
• Compliance and Certifications
• Terms of Service
• Acceptable Use Policy
• Browse and Deploy SKUs