Ruby · 3.3
Ruby hosting, 24/7
Deploy a Sinatra API, a queue worker or an automation written in Ruby and leave it running. Dependencies are installed when the image is built, the process runs in an isolated container and comes back on its own when it falls.
Who designed Ruby
Yukihiro Matsumoto started Ruby in 1993, unhappy with Perl and Python for what he wanted to write. He published in 1995 a language that mixed Smalltalk’s objects, Perl’s expressiveness and blocks in the grammar — the explicit criterion was the joy of the person programming. 1.0 arrived in 1996. Matz kept saying he optimized for humans, not the compiler: syntax should rarely surprise.
Yukihiro Matsumoto
Mathias Meyer · CC BY-SA 2.0
Built for the person writing it
Matz designed Ruby to be a joy, not a compiler target. The difference he wanted from Perl and Python was that: syntax should rarely surprise and should fit in your head.
Everything is an object
Numbers, classes, nil. There is no primitive type on the side. It is object-orientation without the exception Java and C carry in the core.
Blocks in the language
Iteration and resources are not a library callback: the block is grammar. That is the Ruby way to pass behaviour, not an API extra.
What the platform does for a Ruby project
The essentials come configured on every Ruby application here; the features that depend on your plan are flagged in the card.
Three versions, one config line
3.3 is the recommended one, 3.4 is the latest and 3.2 is still available. Switching means changing VERSION in vertracloud.config and deploying again — there is no image to pick and no Dockerfile to maintain.
Gems installed at build time
Installation happens when the image is built, not on every boot. The container starts with everything ready, and an installation failure shows up in the build log instead of becoming a crash in production. The build has 5 minutes.
Auto-restart with a brake
An unhandled exception does not take the service down: the process comes back on its own, on every plan. If it breaks 5 times in 10 minutes, the platform flags a crash loop and turns auto-restart off for 24 hours. Exiting with code 0 does not trigger a restart.
Background today, web tomorrow
A worker runs with no HTTP port. If it later has to answer on the internet, publish the application: it gets a subdomain and TLS. Turning that on and off recreates the container, so the process restarts at that moment.
What people run in Ruby here
The automation that stays up for weeks, and the HTTP service the team publishes when it needs one.
Sinatra and Rack APIs
An HTTP service published on a vertraweb.app subdomain. Bind the server to 0.0.0.0 on port 80 — anything listening on localhost gets no external traffic and the site answers with a timeout.
Workers and queue jobs
A queue consumer, an ETL routine, a periodic task: a long-running process that only has to stay up. Auto-restart covers the occasional fall without anyone waking up to restart it.
Bots and integrations
An automation that stays connected all the time, with no exposed port. The token goes into the environment variables in the dashboard, never inside the zip.
Ruby with a managed database
Create a PostgreSQL 17, MySQL 8.0, MongoDB 8.0.11 or Redis 7 in the same dashboard and connect over the internal host. TLS is mandatory; the certificate and the password are generated by the platform and available to download.
Available Ruby versions
3.3 is the recommended one, 3.4 is the latest and 3.2 is still available. To move off the recommended one, declare VERSION in vertracloud.config.
| Version | vertracloud.config | Status |
|---|---|---|
| 3.4 | VERSION=3.4 | Latest |
| 3.3 | VERSION=3.3 | Recommended |
| 3.2 | VERSION=3.2 |
The whole configuration
vertracloud.config is an optional INI file at the root of the project. MAIN points at the entry file; VERSION picks the Ruby; MEMORY sets the container's RAM ceiling.
NAME=meu-app
MAIN=app.rb
VERSION=3.3
MEMORY=512A plan for every stage of the project
Memory and storage change with the plan; the language does not. Compare what each plan unlocks and pick the one that fits the project today.
Compare plansAlso runs here
Same platform, same deploy, a different stack.
Frequently asked questions about Ruby hosting
Gems, build and variables: what support answers most about Ruby.
Which Ruby versions can I use?
3.3 (recommended), 3.4 (the latest) and 3.2. The choice is made through the VERSION key in vertracloud.config; without it, the application starts on the recommended version.
Do the gems have to travel inside the zip?
No — leave vendor/ out of the package. Gems are installed on the server during the build, for Linux, and the zip accepts at most 100 MB.
My app starts and stops right after. Why?
If the process ends with exit code 0, the platform reads that as a normal termination and does not restart it. Make sure the server is listening or the bot stayed connected: a script that runs to the end and exits does not stay up.
How do environment variables reach the process?
Through the dashboard tab: they are injected into the container at startup and kept encrypted at rest. Up to 25 variables, keys of up to 100 characters and values of up to 1,000. The platform does not read .env files.
How long can the build take?
Up to 5 minutes. If installing the gems goes past that, the build fails — drop dependencies the project does not use. The uploaded zip also has a 100 MB ceiling.
Deploy your Ruby project today
Create the account, send a zip or connect the GitHub repository, and watch the gems being installed in the dashboard terminal.
Create account