Ruby applications, including Ruby on Rails, need a compatible runtime, dependencies and production application server. Confirm the supported environment on your Nabtech plan. A Ruby selector can simplify deployment, but it does not guarantee that every Rails version, native gem or background service is available.
IN THIS ARTICLE
01 Prepare the application requirements
Record the Ruby and framework versions, Gemfile and lockfile, database engine, asset-build tools and background jobs. Review the framework's maintenance policy and choose supported combinations. A newly generated Rails application may assume container or server capabilities that a shared hosting integration does not provide.
- Create the application using the available Ruby selector or agreed server deployment process. Select a compatible runtime and the correct application root.
- Upload the project securely and install its locked dependencies in the application environment. Investigate native extension failures rather than requesting broad server permissions as a first step.
- Set the production environment and secrets through an approved private configuration method. Keep credential files and master keys out of the public document root.
- Configure the supported database connection. Back up existing data before running schema migrations, and understand whether the migration can be reversed.
- Build or precompile assets as required by that application. Configure writable upload and temporary locations without making the entire project publicly writable.
- Start or restart the application through the supported integration and inspect its startup logs.
02 Verify the release
Test HTTPS, authentication, database changes, assets and email. Check background jobs and scheduled tasks separately, since a successful web request does not prove workers are running. Review the error page to ensure private diagnostics are not shown to visitors.
What if my app needs Redis, containers or a custom service?
Confirm availability before deploying. Those requirements may call for a different plan or a managed server arrangement. Do not assume that SSH access authorises installing system packages or running unrestricted daemons.
Keep code, persistent uploads and database backups in your recovery plan. Rolling back source files alone may not undo a database migration or recover newly uploaded customer content.