If you’ve never touched Meltano before, this walkthrough is your starting point. We’ll install the three things you need, then use Claude to add a custom-named environment variable to a real Meltano Cloud pipeline, start to finish, no prior Meltano experience required.
This is written for analytics engineers who’ll eventually write dbt models on top of their data, but every step works if you’re on a marketing or sales team and have never opened a terminal before. Wherever a step assumes some technical comfort, we’ve called out the non-technical way to do the same thing.
This post is the fast, Claude-assisted path through one specific task. For the exhaustive version (every install option, every command, the full extract/load/transform walkthrough), see Meltano’s own Getting Started guide. Worth bookmarking once this walkthrough gets you comfortable.
Does Meltano Honor Custom Env Var Names, or Silently Fall Back?
This wasn’t just a feature demo, it started as an open question worth actually verifying: if you tell Meltano to expose a setting under a custom environment variable name, does that name reliably reach the pipeline at runtime? Or could it silently fall back to Meltano’s own default-generated name instead, quietly breaking anything downstream that expects your custom name?
That’s not a hypothetical. It’s exactly the kind of thing that’s easy to assume works and only discover otherwise once something in production depends on it. So rather than take it on faith, we built the smallest possible pipeline that could prove it one way or the other, and read the actual runtime logs.
The End Result: A Pipeline That Prints Your Own Custom Variable Name
By the end, you’ll have a pipeline running in Meltano Cloud with a setting that shows up under whatever environment variable name you choose, not just whatever name Meltano would pick by default.
You’ll do this by describing what you want to Claude in plain English, letting it write the config, and reviewing its proposed change before anything goes live. If “pull request” is a new term for you: think of it as Claude showing its homework before turning it in, a clear, readable summary of exactly what it wants to change, that you approve before it counts.
Install Git, Python, and Meltano First
1. Git
Git is the tool that tracks every change made to your project’s files, like a detailed version history. Meltano projects live in Git repositories, and Claude uses Git to save and share its changes. Check if you already have it:
git –version
If that prints a version number, you’re set. If not, install Git from the official Git website for your OS.
2. Python (3.10 or newer)
Meltano is built on Python, a programming language, so it needs Python installed to run. Check your version:
python3 –version
Meltano currently supports Python 3.10, 3.11, 3.12, and 3.13. If you’re on an older system Python, Meltano won’t install correctly and the error messages aren’t always obvious about why. The fix: install a newer Python via pyenv, uv, or python.org, rather than trying to force the old one to work.
3. Meltano itself
Once Python is sorted, install Meltano with pipx (recommended, keeps it isolated from other Python tools) or uv:
pipx install meltano
# or
uv tool install meltano
Confirm it worked:
meltano –version
Meltano’s own installation guide covers every option in more depth, including Docker if you’d rather not install anything locally at all.
We hit this exact gap firsthand: on the machine we ran this walkthrough on, meltano, pip, and pipx all came back command not found. Claude worked around it by writing the config files by hand instead, which is fine for a small custom setting like the one in this walkthrough, but isn’t a substitute for having the CLI installed if you’re adding a real connector later. Install it up front and skip the detour.
Not comfortable installing developer tools yourself? This is the one part of the walkthrough worth asking a teammate or your IT/engineering contact to help with once, up front. Everything after this point is plain-English conversation with Claude.
One More Prerequisite: GitHub Access for Claude to Open Pull Requests
This part trips people up because it’s not a Meltano problem: it’s a permissions problem. Claude proposes changes by opening a pull request against your workspace’s Git repository, the same way a teammate would. For that to work:
- You need write access to the repository yourself, someone on your team may need to add you as a collaborator on GitHub first.
- Someone with admin rights on the repo needs to actually approve and merge the pull request. Claude opening it doesn’t skip your team’s review, that’s by design.
If you’re comfortable in a terminal, gh auth status will show you what access your GitHub login has. If not, you can check the same thing by simply trying to open the repository on github.com. If you can see it and there’s an option to make changes, you’re set.
That last point about merging matters more than it sounds like it should. Keep it in mind for the step below: it’s the thing that actually tripped us up.
Step-by-Step: Adding a Custom Variable With Claude
- Clone your Meltano Cloud workspace repository to your machine (or open it directly in a cloud dev environment, if your team uses one).
- Open the repo with Claude and describe what you want in plain language. Here’s the actual prompt that kicked off our test end to end:
“Create a meltano project in this folder with one very simple pipeline. The idea of this pipeline is to add a setting to the meltano.yml, deploy it to the meltano cloud and simply print the env.”
No YAML syntax, no plugin names, just the outcome we wanted.
See what that one prompt actually created: a plugin and a pipeline, not just a setting. Before anything else, Claude had to give the project something to run. In Meltano, every extractor, loader, or utility your project uses is called a plugin, and it’s declared in meltano.yml under plugins. For this test, Claude added a small custom utility plugin called print-env: it just wraps the system’s own env command, so it has no external package to install:
plugins:
utilities:
– name: print-env
namespace: print_env
executable: env
Then it created a pipeline file that references that plugin as its one and only step:
version: pipelines/v0.1
label: Print Env
timeout: 0
max_retries: 0
data_components:
– print-env
- inline_script: env
That’s the whole project from one sentence: a plugin to run, and a pipeline that runs it. Everything from here (the settings, the custom variable name) gets added on top of this. - Confirm the basics work before testing the harder case. Claude added a plain setting (greeting, no custom name) to that same plugin, to establish a baseline. Deployed and run, it showed up in the log as expected:
PRINT_ENV_GREETING=hello-from-meltano-cloud
With the baseline confirmed, Claude moved on to the real test: a setting with a custom env: override.
See what Claude wrote for the real test. Claude added a second setting to the same plugin, with an explicit env: override, the one that actually answers the real question from the top of this post:
utilities:- name: print-env
namespace: print_env
executable: env
settings:
- name: custom_named_setting
kind: string
env: MY_CUSTOM_ENV_VAR
value: hello-custom-env-name
- label: Custom Named Setting
That env: MY_CUSTOM_ENV_VAR line is the whole trick: without it, Meltano would’ve generated a default name on its own instead. - Review the pull request Claude opens. It should show a small, readable diff like the ones above, nothing else. Claude will stop and ask before pushing or opening anything, rather than assuming it should.
- Approve and merge the pull request once it looks right, the same way you’d approve any teammate’s proposed change.
- Deploy the workspace from the Meltano Cloud UI so the platform picks up your change.
- Run the pipeline and open the job log.
- Confirm your variable name appears in the log with the value you expected. Here’s exactly what we saw when it worked:
MY_CUSTOM_ENV_VAR=hello-custom-env-name
We Also Tried It a Second Way: Setting the Value in the Meltano UI Instead of Git
Everything above sets the value by committing it in meltano.yml. But you don’t have to touch code at all to change a setting’s value day-to-day, Meltano Cloud’s Lab UI lets you edit it directly on the pipeline’s Settings tab.
We tested that path too: set the same setting to set-via-ui through the UI (no code change), saved, deployed, and ran the pipeline again. The log showed:
MY_CUSTOM_ENV_VAR=set-via-ui
Same result, either way you set it.
The Verdict: Meltano Honors Custom Env Var Names Every Time
Going back to the real question this walkthrough set out to answer: the custom environment variable name is honored, reliably, whether the value is set in git or through the UI. No dropped override, no silent fallback to a default name.
How to Check It Actually Worked (Not Just “Looks Done”)
Don’t take a green “COMPLETE” on the job as proof your change went live: it’s worth a quick double-check of what it actually deployed. We ran into this directly: after opening a second pull request with a new setting, clicking Deploy again produced a log with the exact same result as before, because the pull request hadn’t been merged yet. Deploy always builds from your repository’s main branch, not from a pull request that’s still open.
The simplest way to catch this: after you deploy, open the pull request on GitHub and confirm it says “Merged” (not just “Open”). If it still says Open, that’s your answer: merge it, then deploy again.
Three Setup Blockers We Hit (and Their Fixes)
| Blocker | What it looks like | Fix |
|---|---|---|
| Python older than Meltano requires | python3 –version shows 3.9 or earlier, below Meltano’s 3.10 minimum | Install Python 3.10+ via pyenv/uv before installing Meltano |
| meltano/pip/pipx not found | command not found after a fresh machine setup | Install Python first, then pipx install meltano, before starting |
| Deploy shows the old result | Same value in the job log after deploying again | Check the pull request actually says “Merged,” not just “Open” |
Once your workspace is set up this way, the second ask is genuinely this easy: a real ticket, handed to Claude as-is:
“Hi Claude, help me understand this and build a plan for fixing this. Linear issue: [link to the ticket]”
No translating the ticket into technical steps yourself. That’s the payoff for getting the prerequisites right the first time.
Why This Takes Minutes, Not Days or Weeks
Teams that build their own custom ingestion tooling from scratch typically spend days to weeks getting a single connector reliably landing data in a warehouse, before any of the ongoing maintenance even starts. This walkthrough, from a bare machine with nothing installed to a running pipeline with a verified custom variable, blockers and all, is an afternoon, most of which is just watching installers finish. And once the one-time setup is done, every ask after this is just a plain-English sentence to Claude.
Run This Same Walkthrough in Your Own Workspace
Once you’ve got this working, the same pattern (describe what you want, review Claude’s pull request, merge, deploy) applies to any pipeline in your workspace. For everything beyond this one walkthrough, Meltano’s Getting Started guide is the canonical reference. If you haven’t set up a Meltano Cloud workspace yet, your account team or Meltano’s own site is the place to start. I’ve left that link out rather than guess the exact sign-up URL; let me know if you want it added and I’ll drop in whatever page you point me to.