Self-hosted CLI
Self-hosted CLI
This page provides documentation for the NVCF Self-hosted CLI, a command-line interface for managing NVIDIA Cloud Functions in self-hosted deployments.
Overview
The NVCF Self-hosted CLI provides:
- Automatic Token Generation: Generate admin tokens and API keys via direct API calls
- Smart State Management: Persistent workflow context eliminates manual ID copying
- Multi-Environment Support: Separate configurations for dev/staging/production
- gRPC Invocation: Native support for gRPC function invocation
- Shell Completion: Autocompletion for bash, zsh, fish, and PowerShell
The CLI is available as a container image from NGC. See self-hosted-artifact-manifest for the full artifact path.
Prerequisites
- Network access to NVCF API endpoints
- NGC CLI installed (for downloading the CLI release from NGC)
Installation
Download from NGC
The CLI is available as a resource from NGC. See download-nvcf-cli for detailed download and extraction instructions.
The downloaded package includes:
nvcf-cli- The CLI binary.nvcf-cli.yaml.template- Configuration templateexamples/- Sample configuration filesUSAGE-GUIDE.md- Detailed usage documentation
Configuration
The CLI uses YAML configuration files. After extracting the CLI, copy the included template:
Configuration files are searched in this order:
- Explicit path via
--configflag (highest priority) - Current directory:
./.nvcf-cli.yaml - Home directory:
~/.nvcf-cli.yaml
Place your .nvcf-cli.yaml in the directory where you run the CLI for project-specific configuration, or in your home directory for global configuration.
Self-Hosted Configuration
For self-hosted deployments, the CLI must be configured to communicate with your gateway. The gateway uses hostname-based routing for HTTP services, which requires proper configuration.
For a complete understanding of how the gateway routes traffic, including architecture diagrams, verification commands, and production DNS/HTTPS setup, see gateway-routing.
Get Your Gateway Address
After deploying the control plane, get your gateway’s external address (this assumes you followed Step 1 of helmfile-installation):
Configuring the CLI
Create your configuration file:
Complete Self-Hosted Configuration:
Example: AWS ELB Configuration
For a typical AWS EKS deployment with an ELB load balancer:
Verifying Your Configuration
After configuring the CLI, verify connectivity:
If you see a 404 error, verify:
- The
api_keys_hostvalue matches your HTTPRoute hostname - The gateway load balancer is accessible
- The API Keys service is running:
kubectl get pods -n api-keys
Why Host Headers? The Envoy Gateway uses hostname-based routing to direct traffic to different backend services through a single load balancer. Without the correct Host header, the gateway cannot match the request to a route and returns 404.
gRPC doesn’t need Host headers because it uses a dedicated TCP listener on port 10081. The gateway routes all traffic on that port directly to the gRPC service without hostname matching.
Production Setup: DNS and HTTPS
The Host header configuration above is designed for testing and development. For production deployments, configure proper DNS and TLS to eliminate the need for Host header overrides.
With proper DNS and HTTPS configured:
- DNS records resolve service hostnames directly to your Gateway’s load balancer
- TLS certificates secure all traffic
- The CLI uses simple URLs without Host header overrides
- Browsers and other clients can access services directly
For complete instructions on setting up DNS records and TLS certificates, see production-dns-https in the Gateway Routing guide.
Multi-Environment Setup
Use the --config flag to manage multiple environments with separate configuration files:
Each configuration maintains separate state files (e.g., ~/.nvcf-cli.dev.state for dev.yaml).
Debug Mode
Enable debug mode for detailed logging by adding to your configuration file:
Or use the --debug flag or NVCF_DEBUG=true environment variable per-command.
Quick Start
For immediate testing, you can use load_tester_supreme from nvcf-onprem (see self-hosted-artifact-manifest), which supports the {"message": "hello world"} request body above. For more function samples, see the nv-cloud-function-helpers repository and function-creation for function creation documentation.
Authentication
The CLI supports two types of authentication tokens:
- Admin Token (NVCF_TOKEN): For function management (create, deploy, update, delete)
- API Key (NVCF_API_KEY): For user operations (invoke, list, queue status)
Generate Admin Token
Refresh Admin Token
Refresh your token while preserving function context:
Generate API Key
Available scopes for API keys (all included by default):
Command Reference
General Commands
API Key Commands
Function Management Commands
Create Function
All function create flags:
Example function JSON:
Deploy Function
The function deploy command group manages deployments with the following subcommands:
Key function deploy create flags:
Example deployment JSON:
List and Get Functions
Update Function
Invoke Function
Additional function invoke flags:
Queue Management
Delete Function
Registry Commands
Manage container registry credentials for function images and Helm charts. For comprehensive setup instructions including IAM configuration for AWS ECR, see third-party-registries-self-hosted.
Troubleshooting
Authentication Errors
401 Unauthorized on function creation:
403 Forbidden on invocation:
Token Expiration
Connection Issues
Token Usage Summary
For additional troubleshooting, see self-hosted-troubleshooting.