Deploy and Host CloudTwin on Railway

CloudTwin is a multi-cloud emulator for AWS, Azure, and GCP with a built-in web dashboard. It provides cloud-compatible APIs for development, testing, CI/CD, and integration workflows without requiring access to real cloud infrastructure.

About Hosting CloudTwin

This deployment runs CloudTwin as a single Railway service.

CloudTwin exposes emulated AWS, Azure, and GCP APIs through one application endpoint and includes a web dashboard for inspecting emulator state and activity.

The dashboard is available at:

/dashboard

CloudTwin can persist emulator state using SQLite stored on a Railway Volume.

No PostgreSQL, Redis, MySQL, MongoDB, or external database is required for standard usage.

Common Use Cases

Develop applications against AWS-compatible APIs
Test Azure service integrations
Test GCP-compatible workflows
Run integration tests without accessing production cloud resources
Build multi-cloud development environments
Test SDK configuration and cloud abstraction layers
Validate applications that support multiple cloud providers
Run CI/CD workflows against disposable cloud APIs
Inspect emulator activity through a web dashboard
Create reusable cloud testing environments for development teams

Dependencies for CloudTwin Hosting

This deployment requires:

CloudTwin container image
Railway networking
A Railway Volume for persistent SQLite storage
AWS, Azure, or GCP-compatible SDKs and clients

CloudTwin does not require:

PostgreSQL
Redis
MySQL
MongoDB
A real AWS account
A real Azure subscription
A real Google Cloud project
Production cloud credentials

Supported Cloud Providers

CloudTwin provides emulated APIs across multiple cloud ecosystems.

AWS

Supported AWS-oriented services may include:

Amazon S3
Amazon SQS
Amazon SNS
Amazon SES
DynamoDB
Lambda
Secrets Manager
Bedrock simulation

Azure

Supported Azure-oriented services may include:

Blob Storage
Queue Storage
Service Bus
Event Grid
Key Vault
Functions

Google Cloud

Supported GCP-oriented services may include:

Cloud Storage
Pub/Sub
Firestore
Cloud Tasks
Secret Manager
Functions

API compatibility can vary by service and CloudTwin version, so advanced workloads should be validated against the specific emulator behavior they depend on.

Networking

CloudTwin uses a single application port:

Railway automatically provides the PORT value for the deployed service. CloudTwin listens on that Railway-assigned port and binds to all network interfaces.

Generate a Railway public domain for the service.

The resulting endpoint will look similar to:

https://your-cloudtwin.up.railway.app

The same domain is used for:

Cloud API requests
Web dashboard access

This single-port design makes CloudTwin simpler to expose publicly than emulators that require a separate port for each service.

Accessing the Dashboard

Open:

https://your-cloudtwin.up.railway.app/dashboard

The dashboard can be used to inspect supported emulator resources and activity.

Depending on the enabled services and CloudTwin version, the dashboard may provide views for:

Service status
Recent events
AWS resources
Azure resources
GCP resources
S3 buckets and objects
SQS queues
SNS topics
SES messages
Emulator event history
Bedrock simulation or playground features

The root domain is primarily used as the CloudTwin API endpoint.

Use /dashboard when you want the browser-based interface.

Persistent Storage

Add a Railway Volume and mount it at:

/data

CloudTwin stores its SQLite database on the mounted volume at:

/data/cloudtwin.db

Using persistent storage allows supported emulator resources to survive container restarts and redeployments.

No external database is required.

Service Architecture

Application / SDK
        │
        │ AWS / Azure / GCP APIs
        ▼
     CloudTwin
   Railway PORT
        │
        ├── AWS APIs
        ├── Azure APIs
        ├── GCP APIs
        ├── /dashboard
        │
        ▼
 /data/cloudtwin.db
        │
        ▼
 Railway Volume

Connecting Applications

Applications can configure their cloud SDKs or clients to use the CloudTwin Railway endpoint instead of real cloud provider endpoints.

Public endpoint:

https://your-cloudtwin.up.railway.app

Applications running inside the same Railway project can alternatively use Railway private networking.

For a service named cloudtwin:

http://cloudtwin.railway.internal:${{PORT}}

Use the endpoint configuration supported by the specific AWS, Azure, or GCP SDK used by your application.

Public and Private Access

For applications inside the same Railway project, private networking is recommended whenever possible.

Example:

http://cloudtwin.railway.internal:${{PORT}}

For applications outside Railway, use the generated public HTTPS domain.

Because CloudTwin routes multiple cloud APIs through the same service, external clients do not require a separate public Railway domain for every emulated provider.

Persistence Modes

CloudTwin can be used with persistent or ephemeral state.

SQLite Mode

SQLite mode is recommended for this Railway deployment.

CloudTwin stores emulator state in the SQLite database located on the Railway Volume:

/data/cloudtwin.db

Use this mode when emulator resources should survive supported restarts and redeployments.

Memory Mode

CloudTwin may also support ephemeral in-memory operation.

In-memory state should be treated as disposable and will not survive service restarts.

For a Railway template intended to provide a reusable development environment, persistent SQLite storage is recommended.

Important Notes

CloudTwin is intended for development, testing, CI, and integration workflows.
It is not a production replacement for AWS, Azure, or Google Cloud.
CloudTwin emulates selected APIs rather than the complete functionality of each cloud provider.
API behavior may differ from real cloud services.
The web dashboard is available at /dashboard.
Cloud APIs and the dashboard share the same Railway-assigned application port.
SQLite persistence can be stored on a Railway Volume mounted at /data.
No PostgreSQL, Redis, MySQL, or MongoDB service is required.
Real AWS, Azure, or GCP credentials are not required for standard emulator usage.
Applications may require explicit endpoint configuration in their cloud SDKs.
Advanced or provider-specific workflows should be validated before relying on emulator behavior.

Why Deploy CloudTwin on Railway?

Railway provides a managed platform for running CloudTwin without requiring users to maintain dedicated servers or multiple local cloud emulators.

Deploying CloudTwin on Railway provides a shared multi-cloud development environment for AWS, Azure, and GCP-compatible workflows with a built-in dashboard and persistent SQLite storage.

It is useful for application development, automated testing, CI pipelines, SDK integration testing, and multi-cloud experimentation without connecting to production cloud resources.