NouveauBlack Friday : 50 % de réduction sur votre premier paiement
Migration de RunCloud

Hébergement WordPress pour les sites se déplaçant hors RunCloud.

RunCloud est un panneau de contrôle sur un serveur que vous louez et possédez. Déplacer est moins une migration qu'un changement de responsable lorsque le noyau a besoin de patching à deux heures du matin.

Fin de la responsabilité du serveurComportement de la pile reproduitMigration gratuite
Pas de serveur à entretenirCocher la parité des pilesMigration gratuiteSauvegardes quotidiennesSSL gratuitAssistance 24h/24 et 7j/7
Vous étiez propriétaire du serveur.

Ce qui change quand le panneau disparaît.

RunCloud a configuré Nginx, PHP-FPM et cron sur votre VPS. La configuration est passée par là, la propriété de la machine ne l'est pas.

Patching cesse d'être votre élément de calendrier

Un panneau vous indique qu'une mise à jour est disponible. Quelqu'un doit encore l'appliquer, le tester et être éveillé si cela va mal. Ici ce n'est pas une tâche de votre côté du tout.

Système d'exploitation géréGestion de PHP

Règles Nginx lisent avant qu'elles ne soient abandonnées

Les blocs de localisation personnalisés, les limites de taux et les règles de réécriture s'accumulent dans un panneau au fil des ans. Nous les lisons et reproduisons le comportement plutôt que de supposer que les défauts n'ont jamais été touchés.

Révision des règlesComportement égal

Système cron remplacé délibérément

RunCloud exécute généralement wp-cron à partir de cron système. C'est la bonne décision, et il doit être recréé ici plutôt que de revenir silencieusement à cron déclenché par le visiteur.

Un réglage de base de données qui vient de votre taille VPS

Les limites de la piscine tampon et de la connexion sur une boîte auto-gérée sont dimensionnées à cette boîte.

Plusieurs sites dédoublés

Les panneaux encouragent plusieurs sites sur un serveur partageant des travailleurs PHP. La séparation est généralement le plus grand changement de performance du mouvement.

La migration

Planifiez les parties qu'une copie ne peut pas apporter.

Les fichiers et la base de données sont la moitié facile. La moitié qui casse les sites est tout ce que RunCloud faisait en dehors de l'installation WordPress.

  • Personnalisations Nginx inventoriées avant le déménagement
  • Reconstitution des emplois de cron système
  • SSL et DNS coupés avec le TTL abaissés en premier
  • Restaurer toute sauvegarde quotidienne depuis le tableau de bord
Règles Nginx
Révisé et reproduit
14 règles
Système cron
Recréé sur notre planificateur
wp-cron éteint
Sites séparés
Travailleurs propres
3 sites
Coupe-papiers
TTL abaissé, DNS déplacé
en cours
Performances

Trois sites qui partageaient une piscine.

La configuration courante de RunCloud met plusieurs sites sur un seul travailleur de PHP partagé par VPS, donc le plus occupé fixe le temps de réponse pour tous.

Isolés
travailleurs par site
Gestion
Correction de OS et PHP
NVMe
stockage sur chaque plan
MagicWP160 ms
Piscine partagée, voisin occupé1350 ms
Pool de tampons sous-dimensionnés700 ms

Comparaison illustrée d'un site partageant un bassin de travailleurs avec deux autres. Vos chiffres dépendent de la taille du VPS et de la façon dont les sites ont été organisés.

Configuration

Ce que nous changeons en sortant de RunCloud

Ces derniers diffèrent d'un site WordPress standard sur le même plan, et chacun suit d'où un VPS géré par un panneau laisse les choses.

ParamètreNotre configurationPourquoi
Personnalisations NginxInventorié par le groupe et reproduit explicitementLes blocs de localisation et les règles de réécriture ajoutés à un panneau sur plusieurs années sont invisibles dans une copie de fichier et de base de données, et le site se comporte différemment au moment où ils sont partis.
Source du cronProgrammeur de la plate-forme, avec WP-Cron laissé désactivé comme il était déjàUn serveur géré par panneau exécute habituellement wp-cron à partir de cron système, donc une migration qui ré-enable tranquillement cron déclenché par le visiteur rend le travail programmé peu fiable pour la première fois depuis des années.
Répartition des travailleursUne piscine par site au lieu d'une piscine partagée par tous les sitesPlusieurs sites sur un VPS partagent un pool PHP-FPM, ce qui signifie que le plus occupé d'entre eux détermine le lent que le plus silencieux ressent.
Taille de la base de donnéesRetiré de la charge de travail plutôt que porté de l'ancien VPSLes paramètres de la piscine tampon et de la connexion sur une boîte autogérée ont été dimensionnés à la mémoire de cette boîte, donc les importer soit gaspille la capacité ou les gaz du site.
Responsabilité du système d'exploitationTransféré entièrement au lieu de notifierUn panneau de contrôle surmonte la mise à jour et laisse toujours une personne responsable de l'appliquer, ce qui est le coût réel des personnes autogestionnaires sous-estimées.
Offres

Des tarifs simples et transparents.

Chaque offre comprend la migration gratuite, les sauvegardes quotidiennes, le SSL et l’assistance 24 h/24, 7 j/7.

MensuelAnnuel
Starter
Pour les sites personnels, blogs et portfolios.
16,67 USD/mois
200 $US par an · économisez 40 $US
  • 1 site WordPress
  • 10 Go de stockage NVMe
  • SSL gratuit
  • Sauvegardes quotidiennes
  • Déploiement en un clic
  • Assistance par tickets
Démarrer l’essai gratuit
Pro★ Le plus populaire
Pour les entreprises en croissance et les boutiques très fréquentées.
66,67 USD/mois
800 $US par an · économisez 160 $US
  • 5 sites WordPress
  • 50 Go de stockage NVMe
  • SSL gratuit
  • Sauvegardes quotidiennes
  • Déploiement en un clic
  • Assistance prioritaire par tickets
Démarrer l’essai gratuit
Enterprise
Pour les agences et les plateformes à fort trafic.
208,33 USD/mois
2 500 $US par an · économisez 500 $US
  • 20 sites WordPress
  • 200 Go de stockage NVMe
  • SSL gratuit
  • Sauvegardes quotidiennes
  • Déploiement en un clic
  • Assistance dédiée
Démarrer l’essai gratuit
Questions fréquentes

Questions fréquentes.

Est-ce que je garde mon VPS après avoir déménagé?
C'est votre décision, mais il n'y a généralement plus rien. Une fois le site servi ici, le serveur est une dépense sans rôle - la plupart des gens l'annulent une semaine ou deux après la coupure, une fois qu'ils sont confiants.
Mes règles Nginx personnalisées survivront-elles ?
Nous répertorions ce que le panneau exécute avant le déplacement et le reproduisons, car ces règles sont invisibles à une copie de fichiers et de bases de données et leur absence se manifeste immédiatement.
J'ai lancé plusieurs sites sur un serveur RunCloud.
Ils deviennent des sites séparés avec leurs propres ressources, ce qui est généralement la plus grande amélioration du déménagement. Sur un pool partagé, le site le plus occupé fixe le temps de réponse pour chaque autre.
Qu'est-ce qui arrive à mes emplois de cron ?
Ils sont recréés sur notre planificateur. Les configurations RunCloud désactivent normalement WP-Cron en faveur du système cron, et nous le conservons de cette façon plutôt que de revenir à la mise à feu sur le trafic des visiteurs.
C'est une baisse de niveau de contrôle ?
Vous perdez l'accès shell à une machine et gagnez à ne jamais en être responsable. Si la raison pour laquelle vous avez choisi RunCloud voulait régler le serveur vous-même, c'est un vrai trade et mérite d'être honnête avant de bouger.

Déplacez RunCloud et arrêtez de maintenir un serveur.

Migration libre, votre comportement Nginx reproduit, et personne sur votre page latérale pour une mise à jour du noyau.