> ## Documentation Index > Fetch the complete documentation index at: https://docs.mka1.com/llms.txt > Use this file to discover all available pages before exploring further. # Manage repositories > Create and manage mka1-repos repositories — org-scoped git repositories for the model weights and datasets that Compute workloads pull from and publish to. mka1-repos is the platform's repository service for model weights and datasets. Every repository is an ordinary git repository with Git LFS, owned by exactly one organization and identified by the pair `/` — for example `meetkai/functionary`. That identifier is the whole point. You push artifacts to the repository from your machine over git, and Compute workloads resolve the same `/` through the platform's Hugging Face-compatible artifact endpoint to train on or serve them. This guide covers both halves: the management API for creating, listing, renaming and deleting repositories, and the two client tools — `git` and the Hugging Face CLI — that move bytes in and out. ## Before you start You need: | Requirement | Notes | | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | API key | Send it as `Authorization: Bearer ` on every request. | | Org owner or admin role | Every repository endpoint is restricted to owners and admins of the organization. There are no per-repository permissions; access is decided by your org role alone. | | `git` and `git-lfs` | Model weights are large binaries; the git host stores them through Git LFS, so install and initialize `git lfs` before the first push. | Repositories always belong to the caller's organization. You never choose the `org` at create time — it is derived from your API key — and you cannot reach another organization's repositories at all. ## Create a repository Pick a name and optionally a description. The name must start with a letter or digit and be at most 100 characters of letters, digits, dots, underscores, and dashes (`^[A-Za-z0-9][A-Za-z0-9._-]{0,99}$`). ```ts MKA1 SDK theme={null} import { SDK } from '@meetkai/mka1'; const sdk = new SDK({ bearerAuth: 'Bearer ', }); const repo = await sdk.repos.create({ createRepoRequest: { name: 'functionary', description: 'Fine-tuned weights for the MeetKai assistant.', }, }); console.log(repo.org, repo.name, repo.id); ``` ```bash curl theme={null} curl https://apigw.mka1.com/api/v1/repos \ --request POST \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer ' \ --data '{ "name": "functionary", "description": "Fine-tuned weights for the MeetKai assistant." }' ``` The response is `201` with the repository: ```json theme={null} { "id": "rqz4h6k2m5n7p9r3t5v7w9x2", "org": "meetkai", "name": "functionary", "description": "Fine-tuned weights for the MeetKai assistant.", "created_at": "2026-07-30T09:15:00Z" } ``` `id` is an opaque, stable identifier — the canonical key that survives renames. `org` and `name` are the user-facing labels that form the repository reference and its URLs. Creation provisions the backing git repository as part of the request. If that provisioning fails, the create returns `502 provision_failed` and nothing is kept, so it is safe to retry. The request body rejects unknown fields, and a name that is already taken in your org returns `409`. ## The repository reference and git URL Two values identify a repository everywhere else on the platform: | Value | Shape | Used for | | -------------------- | ------------------------------------------ | ---------------------------------------------------------------------------------------------- | | Repository reference | `/`, e.g. `meetkai/functionary` | Hugging Face-compatible resolution inside Compute workloads, and tools like ms-swift and vLLM. | | Git URL | `https://git.mka1.com//.git` | `git clone`, `git push`, and Git LFS transfers from your own machines. | The git host authenticates with HTTP basic auth: the username must be your org slug and the password is an MKA1 API key. `org:apikey` is enforced — a username that does not match the organization is rejected. Both values are what you hand to a Compute workload as environment variables — see [Run a fine-tune job](/docs/compute-fine-tune-job) and [Deploy a model server](/docs/compute-deployment). ## List repositories Returns every repository in your organization. ```ts MKA1 SDK theme={null} const { repos } = await sdk.repos.list({}); for (const repo of repos) { console.log(`${repo.org}/${repo.name}`, repo.description); } ``` ```bash curl theme={null} curl https://apigw.mka1.com/api/v1/repos \ --header 'Authorization: Bearer ' ``` ```json theme={null} { "repos": [ { "id": "rqz4h6k2m5n7p9r3t5v7w9x2", "org": "meetkai", "name": "functionary", "description": "Fine-tuned weights for the MeetKai assistant.", "created_at": "2026-07-30T09:15:00Z" }, { "id": "rb8s2d4f6h8j1l3n5q7s9v2x", "org": "meetkai", "name": "support-conversations", "description": "Curated support transcripts for fine-tuning.", "created_at": "2026-07-28T16:40:00Z" } ] } ``` ## Get a repository Read a single repository by its reference. ```ts MKA1 SDK theme={null} const repo = await sdk.repos.get({ org: 'meetkai', name: 'functionary', }); console.log(repo.description); ``` ```bash curl theme={null} curl https://apigw.mka1.com/api/v1/repos/meetkai/functionary \ --header 'Authorization: Bearer ' ``` A repository that does not exist in your org returns `404` — including any repository that belongs to a different org. ## Rename or update a repository Updates are label-only: you can change `name` and `description`, and an omitted field is left unchanged. ```ts MKA1 SDK theme={null} const repo = await sdk.repos.update({ org: 'meetkai', name: 'functionary', patchRepoRequest: { name: 'functionary-v2', }, }); console.log(repo.name); ``` ```bash curl theme={null} curl https://apigw.mka1.com/api/v1/repos/meetkai/functionary \ --request PATCH \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer ' \ --data '{"name": "functionary-v2"}' ``` The repository `id` is stable, so a rename is a metadata update — the git history and stored artifacts are untouched. Renaming to a name that already exists in your org returns `409`. **A rename changes the repository reference and the git URL.** The old `/` stops resolving immediately. Update every git remote, every `REPO`/`REPO_URL` environment value in Compute create bodies, and every training or serving script that referenced the old name. ## Delete a repository ```ts MKA1 SDK theme={null} await sdk.repos.delete({ org: 'meetkai', name: 'functionary', }); ``` ```bash curl theme={null} curl https://apigw.mka1.com/api/v1/repos/meetkai/functionary \ --request DELETE \ --header 'Authorization: Bearer ' ``` The response is `204` with no body. The repository record is removed immediately — that delete is authoritative — while teardown of the backing git storage is best-effort cleanup. A repeated delete of the same reference returns `404`. Deleting a repository removes the repository, its git history, and every stored artifact. This cannot be undone — there is no soft delete and no recovery window. ## Push and pull with git Clone the repository, or add it as a remote of an existing local repository: ```bash theme={null} git clone https://git.mka1.com/meetkai/functionary-train-data.git cd support-conversations ``` ```bash theme={null} # In an existing local repository instead: git remote add mka1 https://git.mka1.com/meetkai/functionary-train-data.git ``` Track large binaries with Git LFS before committing them. Weight files must go through LFS; small text files such as configs, tokenizer definitions, and JSONL datasets can stay in plain git. ```bash theme={null} git lfs install git lfs track "*.safetensors" "*.bin" "*.gguf" git add .gitattributes ``` Then commit and push as usual: ```bash theme={null} git add . git commit -m "Add curated support transcripts" git push origin main # or: git push mka1 main ``` Git authenticates the push with HTTP basic auth. The username must be your org slug and the password is an MKA1 API key — `org:apikey` is enforced, so a username that does not match the organization is rejected: ```text theme={null} Username for 'https://git.mka1.com': meetkai Password for 'https://meetkai@git.mka1.com': ``` For non-interactive pushes (CI, a training box), export the API key as `MK_API_KEY` in the environment (for example from a CI secret) and supply it through a git credential helper, instead of embedding the key in the remote URL, where it would be written to `.git/config`: ```bash theme={null} git config credential.helper '!f() { echo "username=meetkai"; echo "password=$MK_API_KEY"; }; f' ``` Lay out the repository however your training or serving stack expects. The examples in this guide use two repositories: `meetkai/functionary-train-data`, a dataset repository holding JSONL transcripts, and `meetkai/functionary`, a weights repository in the usual Hugging Face layout (`config.json`, tokenizer files, `*.safetensors`). ## Push and pull with the Hugging Face CLI The same repository is reachable over the Hugging Face Hub API. Two environment variables are all the configuration there is — `HF_ENDPOINT` for where, `HF_TOKEN` for who: ```bash theme={null} export HF_ENDPOINT=https://hf.mka1.com export HF_TOKEN= ``` With those set, the ordinary Hugging Face commands operate on your repositories instead of the public hub: ```bash theme={null} hf download meetkai/functionary --local-dir ./base hf download meetkai/functionary-train-data --repo-type dataset --local-dir ./data hf upload meetkai/functionary ./merged . ``` The same two variables work from Python, because `huggingface_hub` reads them by name: ```python theme={null} from huggingface_hub import snapshot_download path = snapshot_download(repo_id="meetkai/functionary") ``` `hf` is the current CLI; older environments ship the same commands as `huggingface-cli`. Unlike git, this path does not need your org slug as a username — the token carries the identity. This is the part that carries over to Compute. A training or serving container sets the same two variables, and ms-swift or vLLM resolves `/` with no code changes — see [Run a fine-tune job](/docs/compute-fine-tune-job) and [Deploy a model server](/docs/compute-deployment). ## Errors Repository endpoints return a uniform envelope with a stable machine-readable code and the request's correlation id: ```json theme={null} { "error": "not_found", "correlation_id": "c0a8f3d2-4b6e-4f1a-9c7d-2e5b8a1f6d3c" } ``` | Status | Code | Meaning | | ------ | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | | `400` | `invalid_name`, `invalid_body` | A name that violates the pattern, or a malformed body or unknown field (bodies reject unknown properties). | | `401` | `unauthorized` | Missing or incomplete org-scoped identity on the request. | | `403` | `forbidden` | The caller is not an owner or admin of the organization. | | `404` | `not_found` | No such repository in your org — a repository in another org is reported as `404`, never `403`, so existence never leaks. | | `409` | `name_taken` | The name is already taken in your org (create or rename). | | `500` | `internal` | An unexpected server-side error. | | `502` | `provision_failed` | The backing git repository could not be created; the repository was not kept, so retry the create. | | `503` | `org_unresolved` | The gateway could not resolve your organization; retry, and contact support if it persists. | ## API reference For the full request and response schemas, open the Repositories groups in the [API Reference](/api-reference/introduction). ## See also * [Run a fine-tune job](/docs/compute-fine-tune-job) - publish merged weights to a repository from a training job. * [Deploy a model server](/docs/compute-deployment) - serve weights straight from a repository with vLLM.