Skip to content
Vidabug
Sign inStart a project

Four ways to connect your software to Vidabug

A live website with a demo account, GitHub, GitLab, Bitbucket or Azure DevOps, or a ZIP of the source: what each one lets Vidabug do.

2 min read · Updated 2026-11-01 · Getting started · Projects Share on LinkedIn

Vidabug films narrated explainer videos of real software, and tests and repairs it. It can start from four kinds of project. Which one you pick decides what Vidabug can see, and what it can change.

1. A live website or web app, with a demo user

Give Vidabug the address of your running app and a demo account to sign in with. Vidabug uses the app the way a new user would, chapter by chapter, and records what it sees.

  • Best for: explainer and training videos, and testing what your users meet today.
  • What Vidabug needs: the address, a test login (never a real customer's), and any steps a new user must follow first.
  • What it can change: nothing. A live app has no source code to repair, so every defect is reported with its screenshot, the steps to reproduce it and the likely cause.

Use a demo or staging account with sample data. The login is stored encrypted and used only inside the private machine that runs your job.

2. A GitHub repository

Install the Vidabug GitHub App on the repositories you choose. Vidabug reads the code, builds and runs the app in a private, isolated cloud machine, and tests it.

  • Best for: testing and repairs, and videos of features that are not live yet.
  • What it can change: only with your authorisation. When you allow repair branches, each fix is committed to a separate branch named after the job, and a pull request is opened for you to review. Nothing is merged into your production code by Vidabug.
  • Without that authorisation: fixes come back as a patch you apply yourself. Nothing is pushed.

3. GitLab, Bitbucket, Azure DevOps or any Git host

Connect the repository with an access token for that host. Vidabug treats it like a GitHub repository: it reads, runs and tests the code, and pushes repair branches only when you authorise them.

4. A ZIP of the source code

Upload a ZIP when the code is not in a hosted repository, or when you would rather not connect one. The upload is scanned for malware, stored privately, and counted against your organisation's storage.

  • What it can change: your ZIP is never altered. Repairs come back as a patch and a report.
  • Deleting it: delete the project and the upload goes with it, along with every production made from it.

Which one should you choose?

You wantConnect
A video of the app as it is todayA live website with a demo user
Bugs found and fixed, reviewed as a pull requestA repository
Fixes without connecting a repositoryA ZIP
A launch: tested, repaired and filmedA repository, plus the live address

Whichever you choose, you see a line-by-line estimate before anything starts, and you approve it.