Laravel-ylläpito rakennettuna sille tavalle jolla julkaiset

Kyllä. Jokaisen paketin mukana tulee täysi SSH-komentotulkki, joten julkaisu on sama Git-pohjainen työnkulku jota jo käytät paikallisesti. Kloonaa repositoriosi suoraan GitHubista, GitLabista tai Bitbucketista tilillesi, aja composer install hakeaksesi vendor-pakettisi ja kopioi sitten tuotantoarvosi .env-tiedostoon. Sieltä Artisan ottaa ohjat: php artisan key:generate asettaa sovellusavaimesi ja php artisan migrate rakentaa tietokantarakenteesi. Myöhemmän version julkaiseminen on yhtä nopeaa — git pull hakemaan uudet commitit, composer install päivittämään riippuvuudet, php artisan migrate mahdollisille uusille migraatioille ja välimuistin päivitys tyhjentämään vanhat asetukset. Koska sinulla on oikea komentotulkki eikä lukittu paneeli, voit seurata lokeja, korjata storage-hakemiston oikeuksia ja ajaa minkä tahansa komennon uudelleen jos jokin vaatii toisen katsauksen. Osoita juurihakemisto public-kansioon, niin sivusto on käytössä HTTPS:n yli.

On — Composer on asennettu jokaiselle tilille ja on jo PATH-polussasi, joten mitään ei tarvitse ladata, purkaa tai määrittää ennen ensimmäistä julkaisuasi. Avaa SSH-istunto heti kun tilisi on otettu käyttöön, niin composer install, composer update, composer require ja composer dump-autoload toimivat kaikki välittömästi oikeaa PHP-binääriä vasten. Sillä on merkitystä Laravelissa, koska kehys ja lähes jokainen lisäämäsi paketti — aloituspaketeista Sanctumiin, Horizoniin ja muihin — haetaan Composerin kautta eikä kommitoida repositorioosi. Pidät oman composer.json- ja composer.lock-tiedostosi, joten ne versiot jotka testaat paikallisesti ovat ne versiot jotka päätyvät palvelimelle. Jos joskus tarvitset ajaa Composeria tietyllä PHP-julkaisulla, voit tehdä niin, koska PHP-versio on valittavissa sivustokohtaisesti. Lyhyesti: riippuvuustyönkulkusi käyttäytyy täsmälleen kuten omalla koneellasi.

Saat modernin PHP 8.x:n, ja valitset hallintapaneelista minkä julkaisun kukin sivusto ajaa. Tuolla joustavuudella on merkitystä, koska jokainen Laravel-versio ilmoittaa vähimmäis-PHP-vaatimuksen — tuoreet julkaisut odottavat PHP 8.1:tä tai uudempaa, kun taas vanhempi pitkäaikaistuettu sovellus voi olla kiinnitetty aiempaan 8.x-käännökseen. Sen sijaan että pakottaisimme yhden ajoympäristön kaikkeen, asetat version verkkotunnuskohtaisesti, jolloin vanha asiakasprojekti ja aivan uusi sovellus voivat elää samalla tilillä ilman ristiriitaa. Valitsimen rinnalla voit virittää ne asetukset joista Laravel välittää: memory_limit raskaammille Artisan-komennoille ja tuonneille, max_execution_time pitkäkestoisille tehtäville sekä OPcachen, jotta käännetty koodisi pysyy lämpimänä muistissa. Version vaihto on välitön ja peruttavissa, mikä tekee PHP-päivityksen testaamisesta vähäriskistä — nosta testiverkkotunnus ensin, varmista että testisi menevät läpi ja siirrä sitten tuotanto perässä yhdellä klikkauksella.

Molemmat ovat täällä ensiluokkaisia. Jonotyötä varten käynnistä pysyvä työntekijä komennolla php artisan queue:work, jolloin työt, ilmoitukset, sähköpostit ja raskaat viennit pyörivät verkkopyynnön ulkopuolella eivätkä estä kävijän sivulatausta. Kun jonon taustalla on Redis, työt poimitaan ja tyhjennetään nopeasti myös todellisessa liikenteessä. Ajastettua työtä varten et lisää pitkää listaa erillisiä ajastusrivejä. Sen sijaan rekisteröit kaiken Laravelin ajastimeen sovelluskoodissasi ja lisäät sitten yhden ajastusmerkinnän joka ajaa php artisan schedule:run -komennon joka minuutti. Siitä yhdestä tehtävästä Laravel päättää mitkä komennot ovat erääntyneet ja laukaisee ne — tuntikoosteet, yölliset siivoukset, viikkoraportit ja niin edelleen. Aja jokaisen julkaisun jälkeen php artisan queue:restart, jotta työntekijäsi lataavat uuden koodin. Se on Laravelin vakiokokoonpano toimimassa täsmälleen niin kuin dokumentaatio kuvaa, eikä alustakohtaisia kiertoteitä tarvitse opetella.

Kyllä. Redis on käytettävissä välimuistiin, istuntojen tallennukseen ja jonoihin, mikä on se yhdistelmä johon useimmat tuotantotason Laravel-sovellukset tarttuvat. Osoita välimuistiajurisi Redisiin, niin kalliit kyselytulokset, renderöidyt sivunosat ja lasketut arvot tarjoillaan muistista sen sijaan että ne rakennettaisiin uudelleen joka osumalla. Siirrä istunnot Redisiin, niin kirjautuneiden tila pysyy nopeana ja johdonmukaisena liikenteen kasvaessa. Aseta jonoyhteytesi Redisiin, niin taustatyöt asetetaan jonoon ja käsitellään hyvin pienellä yleiskuormalla, jolloin työntekijät pysyvät reagoivina piikkien aikana. Kytket kaiken tämän .env-tiedostossasi tavallisilla välimuisti-, istunto- ja jonoajuriasetuksilla — meidän puolellamme ei tarvita räätälöityä määritystä. Koska Redis pitää tämän työjoukon keskusmuistissa eikä levyllä, aiemmin raskailta tuntuneet sivut muuttuvat huomattavasti ketterämmiksi, ja taustakäsittely pysyy perässä sen sijaan että kasautuisi ruuhkaksi liikennepurskeen saapuessa.

Kyllä, ja se on oikea tapa palvella Laravel-sovellusta. Laravel pitää yhden sisääntulopisteen public-hakemistossaan ja säilyttää sovelluskoodisi, .env-tiedostosi ja storage-hakemistosi verkkojuuren yläpuolella, joten mikään arkaluontoinen ei ole tavoitettavissa verkosta. Hallintapaneelista asetat verkkotunnuksesi juurihakemiston projektisi public-kansioon, ja pyynnöt kulkevat index.php-tiedoston kautta täsmälleen niin kuin kehys on tarkoittanut. Yhdistettynä ilmaiseen itsestään uusiutuvaan SSL:ään sovelluksesi vastaa HTTPS:n yli siistein osoittein ilman index.php-osaa osoiterivillä. Storage- ja bootstrap/cache-hakemistojen käyttöoikeudet on suoraviivaista asettaa SSH:n yli, joten välimuisti, istunnot ja tiedostolataukset toimivat ensimmäisellä kerralla. Jos ylläpidät useita sovelluksia yhdellä tilillä, jokainen verkkotunnus saa oman juurihakemistonsa osoitettuna omaan public-kansioonsa, mikä pitää projektit siististi erillään vaikka ne jakavat saman nopean NVMe-palvelimen alla.

Yes. Our team transfers your codebase, exports and imports your MySQL database, and carries over your storage folder so uploaded files and cached data aren't left behind. We bring everything up on a temporary address first so you can confirm queues, the scheduler and Redis-backed sessions all still work, and only then do we walk through the DNS cutover.

Yes, daily backups cover your database and storage directory, giving you a restore point that sits alongside your own Git-based code rollbacks. If a migration or seed command goes wrong, you can restore the previous day's snapshot rather than trying to reverse the damage by hand.

Yes. Addon domains let you point a staging subdomain and your live domain at the same account, each with its own document root and database. Push and test on staging first, run your Artisan migrations there, and only promote to the production domain once you're confident.

Higher tiers support up to 100 MySQL databases, which in practice means room for several Laravel projects — a mix of client sites, side projects and staging copies — on a single account, each with its own domain, database and .env.

Every plan is covered by a 30-day money-back guarantee, so you can deploy your actual project, run it under real traffic, and check queue throughput and Redis caching behave the way you expect before committing beyond the trial period.

Plans are priced in USD starting at $2.42/mo, and geo-currency detection displays that price converted into your local currency at checkout, so what you see is what gets billed rather than a rate you have to calculate yourself. Billing itself runs through Bohzo Ltd (UK).