viclix
Official Viclix CLI — deploy and manage your Viclix projects from the terminal.
Install
pip install viclix
This exposes a viclix command on your PATH.
Quick start
# 1. Log in once with an account API token (Dashboard → Settings → Tokens)
viclix login
# 2. Inside your project's git repo, register + deploy it
cd my-app
viclix init
# 3. Ship changes anytime
viclix deploy
viclix login stores your token in ~/.viclix/config.json. Set VICLIX_HOME
to change that location.
How init picks your repo
- If the repo already has an
originremote,viclix initregisters that repo and branch with Viclix — no GitHub token needed. - If there's no remote yet, it offers to create a private GitHub repository and
push your code (this path needs a GitHub token: pass
--github-token, store one withviclix login --github-token ..., or paste it when prompted).
What the GitHub token needs
Classic token — tick the repo scope. That's the whole setup.
Fine-grained token (github_pat_…) — choosing "All repositories" is not a
permission grant, so set all of these:
| Setting | Value |
|---|---|
| Resource owner | your account (or the org that will own the repo) |
| Repository access | All repositories — "Only select" can't create repos |
| Administration | Read and write — required to create repos |
| Contents | Read and write |
| Metadata | Read-only (selected automatically) |
Without Administration: Read and write, GitHub answers repo creation with
403 Resource not accessible by personal access token. You can add the
permission to an existing token at
https://github.com/settings/personal-access-tokens — no need to regenerate it.
Commands
| Command | What it does |
|---|---|
viclix login |
Save your account token (--token, --base-url, --github-token). |
viclix logout |
Remove stored credentials. |
viclix whoami |
Show which account/endpoint you're logged into. |
viclix init |
Register the current repo as a Viclix project and deploy it. |
viclix deploy |
Commit, push and trigger a rebuild (--full for a full rebuild). |
viclix hotfix |
Push and fast-sync the container (-i reinstall deps, -nr no restart). |
viclix status / viclix info |
Inspect the project. |
viclix logs-build / viclix logs-app |
Tail build / app logs. |
viclix restart / viclix sleep / viclix start |
Lifecycle controls. |
viclix exec --cmd "..." |
Run a command inside the container. |
viclix pip-install [--packages "a b"] |
Install packages in the container. |
Databases, env vars & static files
init and deploy accept the same setup the dashboard wizard offers:
# SQLite (file lives in your repo, referenced by path)
viclix init --db sqlite --sqlite-path ./data/app.db
# SQLite seeded from a local file uploaded out-of-band (large / git-ignored .db)
viclix init --sqlite-file ./local/app.db # implies --db upload
# Managed Postgres (credentials injected as DATABASE_URL)
viclix init --db shared # or: --db dedicated
# Environment variables (file and/or inline, repeatable)
viclix init --env-file .env --env DEBUG=false --env TZ=UTC
# Cached static path
viclix init --static /static/ --cache-max-age 86400
The same flags work on an existing project — viclix deploy --env-file .env,
--static /assets/, or --sqlite-file seed.db applies the change, then pushes
and rebuilds so the next build picks it up. --env merges with existing keys.
| Flag | Applies to | Meaning |
|---|---|---|
--db none|sqlite|upload|shared|dedicated |
init | Database mode. |
--sqlite-path PATH |
init, deploy | Where the .db lives / is written (default ./data/app.db). |
--sqlite-file FILE |
init, deploy | Upload a local .db out-of-band. |
--env-file FILE |
init, deploy | Load a .env. |
--env KEY=VALUE |
init, deploy | Set one var (repeatable). |
--static PREFIX |
init, deploy | Edge-cached static path (e.g. /static/). |
--cache-max-age SECONDS |
init, deploy | Cache duration for the static path. |
Per-project state (its API key) is saved to a .viclix file in the repo, which
is git-ignored by default.
Metadata
Release files for viclix 0.1.87
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| viclix-0.1.87.tar.gz | 116.0 kB | Without provenance | Details for viclix-0.1.87.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| viclix-0.1.87-py3-none-any.whl | Python 3 | none | any | Details for viclix-0.1.87-py3-none-any.whl |
Total release size: 241.9 kB
Release files / viclix-0.1.87.tar.gz
| Download URL | viclix-0.1.87.tar.gz |
|---|---|
| Size | 116.0 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
e521651dbd2969b93659127addcf8d48bd2ea602edc3e8498abbc775453e8026
|
|
BLAKE2b-256 checksum How to use checksums |
4e03b5d7dcdcf95081c5ca88a982629d09bda88f313fb0058f0ff2829ea1b681
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.10.6
|
Release files / viclix-0.1.87-py3-none-any.whl
| Download URL | viclix-0.1.87-py3-none-any.whl |
|---|---|
| Size | 125.9 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
ab4f92b6c4b8b8db66f3913936ce59f9cd25b4659cfe1c3c8dd35ad7b8adb86f
|
|
BLAKE2b-256 checksum How to use checksums |
89e0c791ebc1a65e0e3bd7b164ad40315b3763c19a745319199a2267d3c00e8f
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.10.6
|
Security for viclix 0.1.87
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.