Amongst the latest updates we've made to Webslice is a slick feature that removes almost all the friction from connecting Webslice to your git repo. Here's a quick look at the new and old processes, and some of the thinking that went into this particular improvement.
The old way had too many steps
The steps used to be a bit laborious. You would:
Enter your repo URL
Copy an SSH deploy key
Switch to GitHub (or GitLab, or Bitbucket)
Find the deploy keys settings page and paste the deploy key
Go back to Webslice to copy a webhook URL and secret
Switch back to your provider, find the webhooks settings page and paste those in too
Come back to Webslice, click verify
Hope it works
Configure your branch and deploy mode.
That’s a lot of steps. At least seven interactions across two different interfaces with different steps depending on which provider you use. Make one little mistake, like missing a character in the webhook secret or selecting the wrong events, and you'd be troubleshooting across both systems to figure out why deploys weren't triggering.
It worked, but it wasn't the experience we wanted for something you do every time you set up a new site.
Connect once, deploy from anywhere
Webslice now supports direct integration with GitHub, GitLab, and Bitbucket. Connect your account once at the team level, and every team member can set up git deploys without touching a deploy key or webhook URL again.
The flow is simple:
Click "Connect GitHub" (or GitLab, or Bitbucket)
Authorise access in a popup.
And that's it. You're connected. From that point on, to set up a new site's git deploy you just pick a repo from a searchable list and then select a branch. For subsequent sites, you can even select a repository during website creation - your first deploy can trigger immediately, before you've visited the deploys tab at all.
Why a GitHub App is better than a deploy key
The GitHub integration uses a GitHub App rather than the traditional deploy key approach. This isn't just a different way of doing the same thing—it's a meaningfully better model.
Fine-grained permissions. A deploy key grants read access to an entire repository. A GitHub App requests only the specific permissions it needs. In our case, that means read access to repository contents and metadata. Nothing more.
Short-lived credentials. Deploy keys are permanent. If one is compromised, it has access until someone notices and revokes it. GitHub App tokens expire automatically after one hour and are regenerated on demand. There's no long-lived secret sitting in storage.
No secrets to manage. With deploy keys, you're responsible for a long-lived SSH key pair. With the GitHub App, Webslice generates a fresh access token when it needs one. You never see a key, because there isn't one.
Automatic webhook delivery. Deploy keys don't help with webhooks at all, so you still had to set those up manually. The GitHub App handles webhooks at the application level. Every push event is routed to Webslice automatically, for every repository you've granted access to.
Works at scale. Deploy keys are per-repository. If you have 20 sites, that's 20 deploy keys to manage. A single GitHub App installation covers every repo you've granted access to, and you can adjust the list at any time from your GitHub settings.
GitLab and Bitbucket get the same treatment
GitHub Apps are GitHub-specific, but we've built the same experience for GitLab and Bitbucket using OAuth. The user-facing flow is nearly identical: click connect, authorise in a popup, pick your repo, pick your branch, done.
Behind the scenes, GitLab and Bitbucket OAuth connections handle the deploy key and webhook creation automatically via their APIs. You still get the searchable repo list, the branch dropdown, and the one-click setup - the plumbing is just slightly different.
All three providers use HTTPS token-based cloning instead of SSH, so the entire deploy key infrastructure is bypassed regardless of which provider you use.
What the new setup looks like
When you go to the deploys tab on a new site, you'll see your options laid out clearly:
Connect GitHub
Connect GitLab
Connect Bitbucket
Manual setup - SSH deploy key and webhook, for self-hosted instances or other providers.
If your team has already connected a provider, the repo picker appears immediately with no connection step needed.
Changing your repository or branch after setup is just as easy. Open your website settings, pick a different repo or branch from the dropdown, and you're done. No re-keying, no webhook reconfiguration.
The manual flow isn't going anywhere
The SSH deploy key and webhook flow still works exactly as before. If you're running a self-hosted GitLab instance, using Gitea, or have a security policy that doesn't allow third-party app access, the manual setup is still fully supported.
It's now under a "Manual setup" option rather than being the default path, but nothing about it has changed. Existing sites with manual git configuration continue working with no changes needed.
Questions or feedback?
If you run into anything during setup or want to share how the new flow is working for your team, just get in touch with us.