Skip to content
gtcnsl
Docs Source
EN RU

TUI vs CLI

Bare `gtcnsl` opens an interactive TUI on a terminal; the same actions are scriptable subcommands. Use the UI to explore, the CLI to automate.

Updated for v1.3.0

Two front ends, one engine

Run gtcnsl with no arguments and, on an interactive terminal, it opens the full TUI. On a non-terminal (a pipe, a CI step, nohup) it prints help and exits instead of blocking — so the bare command is safe to leave in a script.

The TUI screens map one-to-one onto subcommands:

TUI screen CLI equivalent
Services gtcnsl gitea install, gtcnsl runner install / register
Config gtcnsl config get / apply / set / toggle
Secrets gtcnsl secrets generate / check / rotate
Doctor gtcnsl doctor
Self-update gtcnsl self-update

Reach for the TUI when

  • you are setting up a box for the first time and want to see the moving parts;
  • you want to read host state (Doctor) without remembering flags;
  • you are making a one-off change and prefer to confirm it visually.

Reach for the CLI when

  • you are automating: CI, provisioning, or a Makefile;
  • your config lives in Git — gtcnsl config apply --template app.ini.tmpl is the declarative path;
  • you want idempotent, repeatable runs.
# unattended: confirm up front, preview with --dry-run
gtcnsl config apply --template app.ini.tmpl --var DOMAIN=git.example.com --dry-run
gtcnsl config apply --template app.ini.tmpl --var DOMAIN=git.example.com --yes
i
Destructive ops need --yes
Anything that writes or restarts requires --yes; --dry-run previews without touching anything. That is what makes the CLI safe to run unattended.

Next steps

Scripting a fresh box? The Quickstart shows the three-command install flow.