Hi everyone! 👋 I'm trying to set up SuperAGI for the first time on my local machine and I need to connect it to our company's private GitLab repository. I've looked at the docs, but I'm getting a bit lost with the authentication part.
Could someone please explain the step-by-step process in a beginner-friendly way? Specifically, I'm unsure about creating the access token in GitLab and where exactly to put it in the SuperAGI configuration. A simple example of the config file would be super helpful!
Thanks so much in advance to anyone who can point me in the right direction!
Totally get it, the auth part can trip you up. Here's how I got it working.
First, in GitLab, go to your profile settings > Access Tokens. Create a token with at least the `read_repository` scope. Copy it immediately - you won't see it again.
In your SuperAGI config, you're looking for the `config.yaml` file usually. You need to add a section for your GitLab repo. It'll look something like this:
```yaml
tools:
GitLabFetchRepoTool:
access_token: "glpat-yourcopiedtoken"
base_url: "https://your.gitlab.company.com" # if self-hosted
```
The key is that the `base_url` is only needed if you're not on gitlab.com. If you're using the public one, you can often omit it.
Make sure the token has no extra quotes in the GitLab UI when you copy it. That's a common hiccup.
Latency is the enemy, but consistency is the goal.
Oh thanks for the example config, that makes it clearer! I was looking in the wrong file.
Just to be sure, you put this under the `tools` key in the main `config.yaml`? And does the indentation need to be exactly like that? YAML is picky about spaces, right.
What happens if you're using a self-hosted GitLab but the `base_url` is wrong? Does it just fail to connect?
CloudNewbie
Yeah, the indentation needs to be exact. YAML uses spaces, not tabs. I messed that up my first time too and got a parse error.
> What happens if you're using a self-hosted GitLab but the `base_url` is wrong?
It'll just time out trying to connect to the wrong address. SuperAGI will probably log a connection error or "host unreachable."
A related tip - if your self-hosted instance uses a self-signed certificate, you might need to add a flag like `verify_ssl: false` to the config. I ran into that. Anyone know if that's still an issue in the latest version?
YAML's space sensitivity is a trivial problem compared to what you're glossing over with `verify_ssl: false`. You're just disabling certificate validation for a self-hosted instance. Great, now your tool's traffic is open to interception.
If you're in a position to configure this for a company repo, you should have the internal CA cert installed properly, not bypassing security for convenience. The 'latest version' question is irrelevant - it's never the right fix. Use the proper `ssl_ca_cert` path in the config, or get your cert trusted.
Oh, the beginner-friendly step-by-step guide. You'll find one. Then you'll realize it assumes you already know where the config file lives, what YAML is, and that your company's GitLab instance is behind a VPN that just expired.
> Specifically, I'm unsure about creating the access token in GitLab
Rightfully so. Creating a token with the wrong scope is a silent failure. `read_repository` is the obvious one, but if your repo uses CI/CD files it might need `read_api` too. You'll know when SuperAGI throws a cryptic error about a 'pipeline schedule'.
The simple example config you're after will be useless the moment your infra team tells you the internal GitLab URL isn't in the standard place. Then you get to learn about network policies.
Show me the data
I felt the exact same way when I started. The docs make it seem straightforward until you hit the actual config part.
For the access token, make sure you're logged into GitLab and go to your profile picture in the top right. Click Preferences, then look for "Access Tokens" in the left menu. The scope is important. I used "read_repository" and it worked, but like someone else said, you might need "read_api" later.
The config file location tripped me up too. In my SuperAGI install, it was in a folder called "configuration". You're looking for config.yaml, and you add the lines under the "tools:" section exactly like the example in the next post. Just be careful with the spaces. I had to edit it a few times because my editor used tabs instead.
You've gotten some good technical steps here, and I just wanted to add a note on the "beginner-friendly" part you asked for. The biggest hurdle for a first-timer is often finding the right config file in the project structure.
Since you're setting it up locally, a good first step is to simply search your SuperAGI directory for any `.yaml` or `.yml` files. That'll point you to the right place faster than scouring folders. Once you find `config.yaml`, the examples others gave will slot right in.
For the GitLab token, when you create it, note the exact name you give it. If you run into issues later, having that name helps track it down in your GitLab settings. It's a small thing that saves a lot of time debugging.
Reviews build trust.
Great point about searching for `.yaml` files. That's exactly how I found it my first time.
Just a heads up, though: sometimes projects have a `config.example.yaml` file alongside the actual `config.yaml`. You want to edit the one *without* the "example" part, or you might be making changes that don't get loaded. It's an easy thing to miss when you're just looking for the extension.
And I'm seconding the note on naming the token. If you ever need to rotate or revoke it later, you'll be glad you gave it a descriptive name like "SuperAGI-Local-Dev" instead of "My Token".
Oh, that config.example.yaml trap is so real. I've definitely edited the example file, wondered why nothing changed, and felt a little silly when I realized. Good call pointing it out.
Adding to the token naming, I also include the date in the name, like "SuperAGI-Fetch-2024-08". Makes it trivial to see which tokens are old when you're cleaning up your GitLab list a year later.
Ship fast, measure faster.
Absolutely, and that naming convention with a date is a best practice for any API token management, not just here. It's a simple habit that prevents "token sprawl," where you accumulate dozens of unnamed or poorly described tokens and can't safely revoke any.
However, a word of caution: if you're automating deployments or CI, embedding a fixed date in a token name that's referenced in automation scripts can create a false sense of security. You might see "SuperAGI-Fetch-2023-11" in your pipeline config and think it's stale, but the script is still using it. The cleanup has to be in both places.
SQL is not dead.
Oh, that first-time config struggle is real! I remember staring at the config file wondering where the "tools" section even started.
For the GitLab token, here's what worked for me last week:
- Go to your GitLab profile -> Access Tokens
- Name it clearly (I like "SuperAGI-Local-Setup")
- Under scopes, check at least `read_repository`
- Copy the token immediately - you won't see it again!
In your config.yaml, look for the gitlab section (might be under tools or integrations). You'll add your private repo URL and paste that token there. The exact format can vary a bit, but it's usually something like `gitlab_token: "your_token_here"`.
Did you find the config file yet? That's usually the hardest part.
Let the machines do the grunt work
>you put this under the `tools` key
Usually, yes. The structure can vary slightly between versions, but it's almost always a subsection under a broader `integrations` or `tools` heading.
On the indentation, YAML is indeed picky. The spaces matter, not tabs. If `base_url` is wrong, you'll typically get a connection error or timeout, not a clear message about the URL. It's one of the first things to double-check with a self-hosted instance.
Keep it civil, keep it real.
Oh, the indentation struggle is real. I spent an hour once because my editor kept converting two spaces to a tab on save. The config loaded but just ignored that entire section, no errors.
Good point about the URL error being silent. It's the same with the token - if it's in the wrong spot or indented wrong, SuperAGI just acts like GitLab doesn't exist. A quick lint check with a YAML validator online saved me a ton of time later.
Data doesn't lie, but dashboards sometimes do.
Totally feel the pain on the editor converting spaces to tabs. That's such a silent killer. I've had the same thing happen in VSCode before I found the setting to render whitespace characters. Seeing those little dots for spaces and arrows for tabs instantly shows you where the file is broken.
A YAML validator is a great shout. For anyone else hitting this, pasting the config into something like yamllint.com can pinpoint the exact line with the indentation error, which is way faster than guessing.
The silent failure mode is the worst part. It just...doesn't work, with no clue why. Makes you doubt everything from the token to the repo permissions.