Swigs Cloud is a hosting platform run in Switzerland by Swigs SA. This connector lets Claude deploy and manage the sites and apps you build together, without a terminal, FTP or build configuration. Ask Claude to put a project online and it sends the files (or a public Git repository) to Swigs Cloud. Static sites (HTML, Vite, React, Vue, Svelte, Angular), Node applications and exports from Lovable, v0 or Bolt are detected automatically. The site gets a free <name>.swigs.cloud address with HTTPS, and runs on two replicas on a three-node cluster. What you can ask: - "Put this site online on Swigs Cloud." - "Change the title on the home page and republish." - "Why did my last deployment fail?" (reads the build log) - "Go back to yesterday's version of my site." (lists the earlier versions, then restores the one you pick) - "Add my Stripe key to the shop." (environment variables; values are never shown back) - "List my projects and tell me which ones are live." - "How many visitors did my site get this week, and from where?" (cookieless analytics, stored in Switzerland) - "Delete the test project." (irreversible, Claude asks you first) Requirements: a Swigs Cloud account (sign up at swigs.cloud with email, Google or GitHub). New accounts get a 30-day trial covering two sites, no card required. After that, websites start at CHF 9 per month and applications at CHF 12 per month, at a fixed price. Data stays in Switzerland. The connector only acts on the projects of the account you connect, through OAuth.
update_site.repo for a public git repository, or files to send the files directly. Use files when you have just written the site in this conversation and it is not on git. Static sites (plain HTML, Vite, React, Vue, Angular, Svelte) and Node apps are detected automatically; a site exported from Lovable, v0 or Bolt deploys as is, with no build configuration. The project name becomes the subdomain unless slug says otherwise. Returns immediately with the final URL: the build then runs in the background, poll project_status to know when it is live. To change a site you already deployed, use update_site. Calling deploy again would create a second project and use up another slot of the quota. Three rules for code you write yourself, each of them a cause of silent failure: (1) a server must listen on the port given by the PORT environment variable and bind 0.0.0.0, never 127.0.0.1, or the health check never passes; (2) the project root must be at the root of what you send, with no wrapping folder, or the build finds nothing to build and still reports success; (3) secrets do not exist at build time, so read them when they are used, not at import, and set them with set_env. Also: no disk is mounted and the site runs on two replicas, so nothing written to a file survives: no SQLite, no local uploads, no sessions on disk.set_analytics.failed state. It is not the running application's log. Long output is truncated to its end, which is where the error is.tar -czf /tmp/site.tar.gz --exclude=node_modules --exclude=.git --exclude=.env --exclude=".env.*" . then curl -sf -T /tmp/site.tar.gz "<url>"; (3) call deploy (new project) or update_site (existing project) with upload set to the identifier. The address works once and expires after 15 minutes; archives up to 200 MB. Never put secrets in the archive: use env or set_env.running means the site is live. created, queued, building and deploying mean the work is still in progress: wait a few seconds and call again. failed means the build did not succeed: call logs to find out why. paused and suspended mean the site is offline on purpose and will not change by waiting: tell the user, do not poll.repo: on a project deployed from files, it rebuilds exactly the same content. Use update_site instead.id: it lists the recent versions that went live (identifier, date, and which one is online) and changes nothing. Then call it again with the deployment_id the user chose. The site is checked after the switch; if the old version does not answer, the current one is put back. Not available for WordPress sites.get_analytics.redeploy instead, which picks up the latest commit.
