01
Plus rapide qu'une extension personnalisée.
Une app DSGo est un bundle statique et un manifeste. Pas de code PHP standard. Pas d'échafaudage de plugin. Pas de canal de mise à jour à écrire vous-même.
POUR AGENCES & FREELANCERS Exécutez des applications créées par l'IA sur les sites WordPress de vos clients : elles lisent les vrais articles, pages et utilisateurs de chaque site, et s'exécutent de manière isolée afin qu'une application défaillante ne puisse pas casser le site.
Créez un widget de réservation une fois. Déployez-le sur chaque site client.
DSGo Apps vous offre une unité plus petite qu'un plugin complet : envoyez un seul bundle à N clients avec une seule commande CLI, mettez-les tous à jour de la même manière. Les déploiements multi-sites et la marque blanche sont sur le plan Studio.
La boucle agence
Un seul bundle. N sites clients.
C'est la même boucle init, login, deploy que les développeurs utilisent, simplement répétée par client. Créez l'application une fois, puis exécutez designsetgo apps login --site et designsetgo apps deploy --site contre le nom d'hôte de chaque client. Chaque installation lit les propres données WordPress de ce client.
Consultez la page des développeurs pour le guide complet de la CLI. La boucle init, login, deploy →
Déployer sur plusieurs sites
Une petite boucle bash est la « déploiement multi-site ».
Pas de gestionnaire de flotte personnalisé. Le CLI prend un seul --site par appel ; les agences l'intègrent dans n'importe quelle orchestration existante, une boucle shell, une matrice CI, une tâche Ansible.
# Build once. npm run build # Ship the same dist/ to every client. for site in client-1.com client-2.com client-3.com; do designsetgo apps deploy --site "$site" --no-build done
En CI, la même boucle devient une étape matrix dans GitHub Actions, avec des secrets par site. Il existe une deploy-action de démarrage qui encapsule le CLI.
Pourquoi les agences adoptent ceci
Unité plus petite, marge plus élevée.
02
Plus sûr qu'un snippet.
Un bug dans un plugin snippet casse le site. Un bug dans une app DSGo casse l'app. Le sandbox rend « déployer sur tous les clients vendredi » une idée acceptable.
03
Facturation en tant que service récurrent.
« La suite de réservation » ou « le portail client » est maintenant un SKU. Un bundle, N clients, un tarif mensuel. Vous le maintenez une fois, pas N fois.
White-label
Remplacez notre marque par la vôtre.
La page DSGo Apps de wp-admin, l'écran d'installation, les états vides, tout cela peut porter le nom et le logo de votre agence au lieu des nôtres. Les clients voient votre marque gérer leurs outils de site, et non une extension tierce que vous revendez.
01
Votre nom, votre logo.
Définissez plugin_name et logo_url dans les paramètres de white-label. Chaque surface d'administration les reprend : élément de menu, écran d'installation, cartes d'application.
02
Vos liens d'assistance.
Remplacez nos documents et nos liens d'assistance par les vôtres. Les clients vous posent des questions au lieu de consulter le forum open-source.
03
Pré-empaqueté avec vos applications.
Livrez un seul fichier zip qui installe l'extension, applique votre marque et pré-installe votre portail ou votre pack de réservation. L'intégration des nouveaux clients passe d'une liste de contrôle de configuration à un seul téléchargement.
La marque blanche est incluse sur le plan Studio. Pro peut exécuter le déploiement CLI multi-sites mais est livré sous le nom DesignSetGo Apps. Voir la tarification →
Registre privé de modèles
Votre bibliothèque de démarrage, indépendante de la version publique.
Hébergez vos propres bundles à n'importe quelle URL HTTPS que vous contrôlez. Votre équipe génère l'échafaudage des nouveaux projets clients à partir de votre bibliothèque, pas du starter public.
01
Une configuration par machine de développement.
Exécutez designsetgo apps registry add acme https://acme.example/registry.json --token xxx une fois. Après cela, chaque apps init peut extraire de votre bibliothèque par alias.
02
Starters versionnés.
Épinglez une version spécifique du modèle (--template booking-widget@1.4.0) ou prenez la dernière. Vérification d'intégrité SHA-256 à chaque téléchargement, donc une archive compromise refuse de s'installer.
03
Apparaît aussi dans Riff.
Une fois configuré sur un site, le générateur Riff dans l'admin répertorie vos modèles privés aux côtés des modèles publics, avec une affordance en un clic « Copier la commande CLI » pour vos développeurs.
designsetgo apps registry add acme https://acme.example/registry.json --token xxx designsetgo apps init clients/new-site --template booking-widget --registry acme
Vous apportez les octets (GitHub Pages, S3, votre propre site WP, CDN interne) ; DSGo fournit la spécification et la plomberie CLI. Disponible sur le plan Studio. Voir la tarification →
Modèle de confiance
Choisissez le mode de rendu en fonction de qui a écrit le code.
La plupart des applications d'agence sont examinées en interne. Le mode en ligne est le bon choix par défaut : pages WordPress réelles, SEO natif, montable à la racine. Le mode iframe est le bon choix pour les bundles fournis par des clients que vous n'avez pas écrits vous-même.
Mode en ligne
L'application s'affiche comme une vraie page WordPress. Explorable, indexable, enveloppable par le thème, optimisée pour le SEO. La CSP et la sanitisation HTML s'exécutent à chaque requête. Le bundle est votre propre code, donc le modèle de confiance est une « extension de confiance que vous fournissez ».
"isolation": "inline" Mode iframe
Un bac à sable imposé par le navigateur avec une origine opaque. Utilisez-le quand un client vous remet un bundle HTML d'un indépendant ou d'un artefact Claude enregistré. Le pont continue de fonctionner ; la page ne partage pas l'origine avec le reste du site.
"isolation": "iframe" Référence CLI
Chaque commande, chaque option.
Y compris --site, --sites, --from-artifact, et la deploy-action pour CI.
$ designsetgo apps init booking-pack --astro $ designsetgo apps login --site client-1.com $ designsetgo apps login --site client-2.com $ for s in client-1.com client-2.com; do > designsetgo apps deploy --site "$s" > done ✓ deployed to 2 sites └ same app id, atomic per site