Webbhotell med Ruby-stöd
Ruby on Rails behöver en dedikerad applikationsserver, ett eget Ruby-runtime och ofta en bakgrundsjobbsprocess som körs parallellt. Det gör att Ruby-hosting i praktiken är förbehållet VPS, molnplattformar och dedikerade servrar. På delad hosting är Ruby sällsynt och ofta med begränsat stöd för moderna gems.
Det finns i dag ett brett utbud av alternativ: VPS där du konfigurerar servern själv, eller PaaS-tjänster som Render, Railway och Fly.io som tar hand om driftsättning och skalning.
Utforska webbhotell efter ämne
Ruby är elegant, men webbhotellen hänger inte med
Ruby är ett av de mer eleganta programspråken som finns, men det är inte gjort för den infrastruktur som dominerar svensk delad hosting. De flesta svenska webbhotell har byggt sina plattformar kring PHP och kör Apache eller LiteSpeed med en kontrollpanel som cPanel eller DirectAdmin. Ruby och särskilt ramverket Ruby on Rails bryter mot det mönstret ganska hårt. Det syns i utbudet: leta länge bland svenska delade webbhotell efter ordentligt Rails-stöd, och du hittar nästan ingenting.
Det handlar inte om att leverantörerna är lata. Problemet är arkitekturellt. PHP körs som en modulprocess eller FastCGI direkt i webbservern. En Rails-applikation är en fristående process som behöver en applikationsserver, typiskt Puma eller Unicorn, och en proxyserver framför sig. Det kräver SSH-åtkomst för att starta och hantera processen, möjlighet att installera gems via Bundler, och ibland dedikerade portar. På delad hosting med strikt process-isolering och standardiserade PHP-miljöer finns inte det utrymmet.
Där stöd faktiskt dyker upp på delad hosting är det ofta via Phusion Passenger, en applikationsserver som integrerar direkt med Apache och Nginx. Passenger löser processen bakom kulisserna och låter hotellets webbserver prata med Rails som om det vore ett vanligt PHP-skript. Det fungerar, men kräver att hotellet faktiskt installerat och konfigurerat Passenger, och det är sällsynt bland svenska leverantörer. Internationellt hittar du det lite lättare, framför allt hos leverantörer med äldre cPanel-konfigurationer.
VPS är oftast rätt svar
Ärligheten kräver att vi säger det rakt ut: för ett seriöst Rails-projekt är en VPS den självklara lösningen. Du väljer din egen Ruby-version via rbenv eller RVM, installerar Bundler, konfigurerar Puma och sätter upp Nginx eller Caddy framför. Du bestämmer miljön helt, och Rails körs som det är tänkt. Kostnaden för en enkel VPS hamnar i samma spann som ett mellanprissatt webbhotell, men du får kontroll och förutsägbarhet som inget delat hotell kan matcha.
En annan sak att ha klart för sig är att Rails-applikationer ofta förutsätter PostgreSQL framför MySQL. De flesta delade webbhotell erbjuder bara MySQL. Det är inte omöjligt att köra Rails mot MySQL, men Postgres är vad ekosystemet anpassat sig mot, och ActiveRecord-migrationer beter sig på ett sätt som Postgres-användare tar för givet. På en VPS väljer du databas fritt. På delad hosting är du bunden till vad hotellet erbjuder. Vill du arbeta med Rails och data på allvar är det ännu ett argument för utvecklarinriktat webbhotell med full kontroll.
Kontrollera Passenger-stödet innan du köper
Många webbhotell nämner Ruby på sin tekniksida utan att specificera hur det faktiskt levereras. Om Phusion Passenger inte nämns explicit, och om du inte kan se en Ruby-version i kontrollpanelen, är chansen stor att stödet inte är produktionsdugligt. Fråga supporten konkret: 'Kan jag köra en Ruby on Rails-applikation via Passenger på ert delade webbhotell?' Svaret avslöjar mer än specifikationssidan.
Kravlista för ett Ruby/Rails-webbhotell
- SSH-åtkomstUtan SSH kan du inte installera gems, köra migrationer eller starta om applikationsprocessen. Det är ett hårt krav.
- Phusion Passenger eller egen applikationsserverPassenger integrerat med webbservern är det smidigaste alternativet på delad hosting. På VPS konfigurerar du Puma eller Unicorn själv.
- rbenv eller RVM för versionshanteringRätt Ruby-version är kritisk. Rails 7 och 8 kräver Ruby 3.x. Hotellet måste antingen erbjuda rätt version eller låta dig installera din egen via rbenv/RVM.
- Bundler och geminstallationbundle install måste kunna köra utan behörighetsproblem. På begränsade delade miljöer blockeras ofta gem-installationer utanför hotellets egna kataloger.
- PostgreSQL eller MySQLPostgres är standardvalet i Rails-ekosystemet. Om hotellet bara erbjuder MySQL går det att lösa, men planera för det i din Gemfile och databaskonfiguration.
- Tillräckligt minne per processEn Rails-process tar betydligt mer minne än ett PHP-skript, ofta 200-400 MB per worker-process. Det är sällan tillgängligt på billig delad hosting.
Vanliga frågor om webbhotell med Ruby-stöd
Ruby on Rails och hostingmiljön
Tekniskt möjligt på de få delade webbhotell som erbjuder Ruby, men sällan praktiskt för en Rails-applikation i produktion. Delad hosting saknar ofta rätt Ruby-version, Passenger-konfiguration och tillräckligt RAM för att Rails startprocess ska fungera stabilt. Det klassiska problemet är att applikationen startar om sig vid varje förfrågan istället för att hålla sig varm i minnet, vilket ger sekunder långa svarstider. En VPS med minst 1 GB RAM och rot-åtkomst är det vanliga svaret för allt utom de enklaste demo-miljöerna.
Passenger (officiellt Phusion Passenger) är en applikationsserver som kopplar ihop Ruby-processen med webbservern Apache eller Nginx. Utan en sådan koppling kan webbservern inte prata med din Rails- eller Sinatra-applikation. På ett VPS installerar du Passenger själv och styr dess konfiguration fullt ut. På de få delade hostingar som stöder Ruby finns Passenger ibland förinstallerat och aktiveras via en .htaccess-rad, men du har då ingen kontroll över version eller processmodell. Alternativa applikationsservrar är Puma och Unicorn, som i modern Rails-drift ofta föredras framför Passenger på VPS.
Rails-applikationer håller en hel runtime-process varm i minnet, kräver bakgrundsjobb (Sidekiq, Solid Queue), databaskopplingar och ibland Redis. På ett delat webbhotell delar du RAM, CPU och processantal med hundratals andra sajter, och värden begränsar ofta antalet körande processer per konto. Det räcker för att en Rails-app ska misslyckas under last eller överhuvudtaget inte starta. Med ett VPS väljer du Ruby-version, paketerar gem-beroenden exakt och konfigurerar webbservern utan begränsningar. Kostnaden för ett enkelt VPS är idag låg nog att den sällan motiverar kompromissen med delad hosting.
Gems, Bundler och databaser
Bundler löser det här med flaggan --path vendor/bundle, vilket gör att alla gems installeras inuti applikationsmappen istället för i systemets gem-katalog. Kör bundle install --path vendor/bundle en gång, och Bundler minns inställningen i .bundle/config. Fördelen är att gems är isolerade per applikation och du slipper versionskonflikter med systemets Ruby. Nackdelen på delad hosting är att gem-mappen kan bli stor och värdleverantörens inode-limit kan orsaka problem vid installation av gems med många beroenden.
PostgreSQL är förstahandsvalet för Rails-projekt som ska skalas, delvis för att Rails ActiveRecord har utmärkt PostgreSQL-stöd och Heroku historiskt normaliserade den kombinationen. MySQL och MariaDB fungerar lika bra för de flesta applikationer och är vanligare på traditionella svenska webbhotell. SQLite passar enbart för lokalt testande eller enkla läs-tunga sajter utan skrivkoncurrens. Väljer du ett VPS bestämmer du själv databas. På delad hosting är du begränsad till vad leverantören erbjuder, oftast MySQL.
Ja. Jekyll och Middleman genererar statiska sajter från Ruby-kod och behöver ingen körande Ruby-process på servern, bara ett webbhotell med vanligt filhosting. Du bygger sajten lokalt med jekyll build och laddar upp den färdiga HTML-mappen. Det är ett populärt mönster för dokumentationssajter och enklare bloggar som vill slippa driftsätta en Rails-app. Kräver du däremot dynamisk logik, inloggning eller en databas är du tillbaka på behovet av en miljö med körande Ruby-process.