• English

      • Use Luna CLI

      Luna CLI manages Luna DevOps from a terminal or automation script. Read Install first if needed.

      Command format

      luna <category> <operation> key=value

      For example:

      luna project list
luna project use project=xnn-api

      List commands default to visibility=related. Platform administrators pass visibility=all only when they explicitly need platform-wide results, for example luna project list visibility=all. Resource queries with a known project space should still pass its project reference to narrow the result.

      Use layered help to find arguments and examples:

      luna --help
luna project --help
luna project list --help

      Run luna doctor first for connectivity, authentication, or version problems.

      IDs and readable identifiers

      Command parameters retain the API names projectId, applicationId, and targetId, but interactive users can pass either a stable ID or the exact immutable identifier in its scope:

      • projectId: a randomly generated, immutable, non-sequential prj_... primary key or a project-space identifier such as xnn-api;
      • applicationId: an app_... ID or an application identifier within the resolved project;
      • targetId: a dplt_... ID or a deployment stage such as prod within the resolved application.

      The CLI resolves these references one scope at a time and converts them to stable IDs before confirming a high-risk operation or sending the business request. It does not guess from display names; a missing or ambiguous reference returns a stable error and points to the corresponding list command.

      releaseId is the randomly generated, immutable rel_... ID of one release record. It is not an application ID, deployment-target ID, or Kubernetes workload name. For example, a name such as luna-postgres-w8kt4h-prod is a generated Kubernetes resource name, not a releaseId. Use the deployment-target command below to enter the current workload.

      Open an interactive deployment-target terminal

      Sign in with OAuth, then attach the local terminal to a running deployment target:

      luna deployment exec projectId=xnn-api applicationId=postgres-api targetId=prod
luna deployment exec projectId=prj_111111111111111111111111 applicationId=app_222222222222222222222222 targetId=dplt_333333333333333333333333 container=api

      Once connected, the local terminal is attached to the shell in the deployment target's current workload container. Run exit or press Ctrl-D to end the remote session and restore the local terminal. deployment terminal is an alias for the same human command. The old release exec entry point remains only for compatibility; it still requires a real rel_... ID and connects to the current workload of that release's deployment target, not a historical release snapshot.

      The command requires an interactive TTY, sufficient project permissions for the current account, and runtime-terminal access enabled for the project space and deployment target. It does not expose cluster credentials and cannot run in a script or Agent mode.

      Copy a command from the Web console

      Application and cluster Web Consoles show the corresponding Luna CLI command in their command bar. Use the copy button to paste it into a local terminal; the question-mark button opens this CLI documentation.

      Commands generated by the platform include the current Luna DevOps server and stable resource IDs already known by the page. They never include tokens, one-time terminal tickets, --yes, or TLS-bypass options. The command runs as the account currently signed in to the local CLI, and the server still rechecks permissions and runtime-terminal policy. Seeing a copy action in the browser does not guarantee that execution will be authorized.

      Permissions and sessions

      After sign-in, Luna CLI has the same permissions as the current account and does not require a separate scope selection. The platform re-evaluates the account's platform role, project-space membership, and resource policy on every request; CLI neither expands nor caches those permissions. Personal tokens and third-party OAuth applications retain their own authorization scopes.

      Logins to the same OAuth application from different devices or terminals form independent sessions. Signing out or revoking the current token affects only that session. Revoking the entire application authorization from account authorization settings invalidates every session for that application.

      Scripts and Agents

      Automation should use JSON output with interaction disabled:

      luna project list output=json interactive=false

      Strict agent=true mode does not resolve readable references; pass stable IDs for resource parameters.

      High-risk operations still require explicit confirmation, and CLI never bypasses platform authorization. Pass tokens through environment variables or a secret manager instead of command history. Use luna help as the command and argument reference.