Deploy Moto Server
A local in-memory AWS instance for use with any AWS client.
Just deployed
Deploy and Host Moto Server on Railway
Moto Server is a lightweight in-memory AWS service emulator that provides AWS-compatible APIs for development, testing, and automation. It allows applications, AWS SDKs, CLI tools, and test suites to interact with mocked AWS services without connecting to real AWS infrastructure.
About Hosting Moto Server
This template deploys Moto in standalone server mode on Railway using the official motoserver/moto container.
Moto Server exposes a single HTTP endpoint that can be used by AWS-compatible clients such as AWS CLI, boto3, AWS SDK for JavaScript, Java AWS SDK, Terraform, and other tools that support custom AWS endpoints.
Moto stores its mocked resources primarily in memory, making it well suited for disposable development environments, automated testing, CI workflows, and API integration testing.
No external PostgreSQL, MySQL, Redis, or persistent Railway Volume is required for the standard deployment.
Common Use Cases
- Mock AWS services during application development
- Run integration tests without connecting to a real AWS account
- Test AWS SDK and AWS CLI integrations
- Create disposable AWS-compatible environments for CI/CD
- Develop against supported AWS APIs such as S3, DynamoDB, SQS, SNS, IAM, and Secrets Manager
- Test applications without creating real cloud resources or incurring AWS usage costs
Dependencies for Moto Server Hosting
- Moto Server Docker image
- Railway public or private networking
- An AWS-compatible SDK, CLI, application, or testing tool
Moto Server does not require:
- PostgreSQL
- MySQL
- Redis
- External object storage
- A persistent Railway Volume for standard in-memory usage
- Real AWS credentials
Accessing Moto Server
After deployment, generate a Railway public domain for the Moto service.
Your main endpoint will look similar to:
https://your-moto-server.up.railway.app
This root URL is primarily an AWS API endpoint, not a conventional web application homepage.
Opening the root domain directly in a browser may therefore display an AWS-style XML response such as:
<Error>
<Code>NoSuchBucket</Code>
<Message>The specified bucket does not exist</Message>
</Error>
This does not necessarily indicate that Moto Server is broken. It means the request reached Moto and was interpreted by one of its AWS-compatible service handlers.
Moto Web UI
Moto includes a lightweight web interface that can be accessed at:
/moto-api/
For example:
https://your-moto-server.up.railway.app/moto-api/
Use this path when you want to open Moto from a browser.
The Moto UI can be useful for inspecting the current emulator state and confirming that the server is running.
The root
/endpoint should not be treated as the Moto dashboard. Use/moto-api/instead.
Connecting AWS Clients
For normal usage, applications should connect to the root Moto endpoint as a custom AWS endpoint.
For example with AWS CLI:
aws s3api list-buckets \
--endpoint-url https://your-moto-server.up.railway.app \
--region us-east-1
You can then create resources normally through AWS-compatible APIs.
For example:
aws s3api create-bucket \
--bucket moto-test \
--endpoint-url https://your-moto-server.up.railway.app \
--region us-east-1
AWS clients can use test credentials when communicating with Moto. Moto does not require real AWS credentials because it does not connect to AWS.
AWS SDK Example
Configure your AWS SDK to use the Moto Server endpoint instead of the real AWS API endpoint.
For example with JavaScript:
import { S3Client } from "@aws-sdk/client-s3";
const s3 = new S3Client({
region: "us-east-1",
endpoint: "https://your-moto-server.up.railway.app",
credentials: {
accessKeyId: "test",
secretAccessKey: "test",
},
forcePathStyle: true,
});
Applications running inside the same Railway project can alternatively communicate with Moto using Railway private networking.
Persistence
Moto Server is primarily designed as an in-memory AWS emulator.
Resources created inside Moto should therefore be treated as disposable and may be lost when the service restarts or is redeployed.
A Railway Volume is intentionally not included in this template because standard Moto Server usage does not require external persistent storage.
This makes Moto particularly suitable for testing environments where infrastructure needs to be quickly created, reset, and recreated.
Docker-Dependent Services
Most Moto API emulation runs directly inside the Moto Server container.
However, some emulated AWS functionality may require Moto to launch additional Docker containers. AWS Lambda execution is one example.
Railway services do not normally expose a Docker daemon or host Docker socket to application containers.
Docker-dependent Moto functionality may therefore be unavailable with this deployment.
This template is best suited for AWS API mocking and services that Moto can emulate directly within its own container.
Important Notes
- Moto Server is primarily an API emulator, not a traditional web application.
- Use
/moto-api/to access the Moto web interface. - Use the root Railway domain as the AWS-compatible API endpoint.
- AWS clients can use test credentials when communicating with Moto.
- Moto data should be considered temporary and disposable.
- Redis, PostgreSQL, MySQL, and Railway Volumes are not required for standard usage.
- Some Docker-dependent AWS emulation features may not work on Railway.
Why Deploy Moto Server on Railway?
Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.
Deploying Moto Server on Railway provides a reusable AWS-compatible testing endpoint that can be accessed by development environments, CI pipelines, applications, and team members without requiring everyone to run Moto locally.
Template Content
