Gyro Containers limits and rules: SMTP, resources, persistent disk and security
1. Summary table
| Topic | Status |
|---|---|
| Running user | Non-root (default 10001); no privilege escalation |
| Port | 1024 and above recommended; a public service needs a single port |
| Access from outside | HTTPS only (name-code.gyroapp.net and your own domains). Raw TCP/UDP ports cannot be exposed |
| Outbound SMTP (25) | Closed |
| Other outbound connections | Open (587 and 465 included) |
| Persistent disk | None; files are deleted on restart (/tmp is 512 MiB, temporary) |
| Scheduled jobs (cron) | None; use a scheduler inside your application for periodic work |
| Service / replica / domain limits | Per package: 10/20/40 services, 5/10/20 replicas, 5/10/20 domains |
| Resources | CPU and memory reserved per replica are guaranteed and cannot be exceeded |
| Log retention | 14 days |
2. Network rules
- Inbound: Only services you mark public are reachable, and only over HTTPS. Services in the same environment reach each other freely at
http://service-name. You cannot be reached from other customers' environments. - Outbound: Your containers can reach the internet but cannot reach private networks (internal IP ranges) or Gyro infrastructure addresses.
- SMTP (port 25) is closed. To prevent spam abuse containers cannot connect directly to mail servers. To send email use an authenticated mail service on port 587 or 465 (your own SMTP provider or Business Email) or an email API.
- Containers cannot go out and connect to their own public
*.gyroapp.netaddresses. Reach services in the same environment through the internal address (http://service-name).
3. Resource limits
- Each replica reserves the CPU and memory you choose; you cannot exceed your capacity (your nodes minus the system share).
- A container that exceeds its memory limit is stopped (OOMKilled) and restarts; exceeding CPU slows it down.
- Sustained high resource use is not a problem, but cryptocurrency mining and similar abuse are forbidden.
4. Disk and data
A container's file system is temporary. Write data that must persist to:
- For files: Object Storage (S3).
- For a database: a separate server or a managed database service.
There is no backup commitment for Gyro Containers; protect your application code and data with your own backups.
5. Security and usage rules
- Containers are isolated; nodes belong only to you and network traffic between environments is closed.
- Images may go through a security scan when used; malicious images such as crypto miners are rejected ("This image cannot be used on the platform" / "The image failed the security scan").
- Do not bake credentials into images; use secrets.
- Illegal content, spam, attack and scanning tools and anything forbidden by the Gyro service agreement and the server usage rules are forbidden on this service too. The service can be suspended for a violation.
- Fair use: no TB quota is stated for network traffic; a fair-use principle applies.
6. Frequently asked questions
Why is SMTP 25 closed?
Sending mail straight to servers from containers is the most common route of spam abuse. Authenticated sending on 587/465 is allowed.
Can I run a database?
Technically you can run a database image, but because its disk is not persistent your data is lost on restart. A separate server is recommended for a production database.
Can I run cron or scheduled jobs?
There is no separate scheduled-job type. Use a scheduler inside your service (for example a library) or an external trigger (a service that calls a URL).
Can I run a raw TCP service or a game server?
Only HTTPS services are exposed to the internet. For applications needing a raw TCP/UDP port a Gyro Cloud Istanbul server is more suitable.
Next step
Thanks for your feedback!