Mastering kubectl port-forward: Essential Guide & Tips

Kubernetes, the de facto standard for container orchestration, offers an unparalleled level of flexibility and power for deploying and managing applications at scale. Within its expansive toolkit, one command frequently stands out as an indispensable companion for developers and operators alike: kubectl port-forward. While seemingly simple, mastering this command unlocks a direct, secure channel to interact with services running inside your cluster, bypassing the complexities of external exposure. This comprehensive guide will delve into every facet of kubectl port-forward, exploring its mechanics, diverse applications, advanced techniques, security implications, and common troubleshooting scenarios. Our goal is to equip you with the knowledge to wield this command with confidence, significantly streamlining your development and debugging workflows.

The Genesis of a Problem: Reaching Inaccessible Services

Imagine you’ve deployed a microservice application into your Kubernetes cluster. Your frontend service is exposed via an Ingress, making it accessible from your browser. However, what about a backend database, a caching layer, or an internal API service that should never be exposed directly to the public internet? How do you, as a developer, interact with that database to inspect its contents, or test a specific API endpoint without deploying a full client application within the cluster itself?

Traditional methods might involve creating a temporary NodePort or LoadBalancer service, which opens up ports on your cluster nodes or provisions external load balancers. While functional, these methods are often overkill, create security vulnerabilities by exposing internal services, and incur unnecessary resource consumption or cloud costs for temporary access. This is precisely the scenario where kubectl port-forward shines, providing an elegant and secure solution.

Unveiling kubectl port-forward: Your Direct Tunnel to the Cluster

At its core, kubectl port-forward establishes a secure, bidirectional tunnel between a local port on your machine and a specific port on a pod (or service, deployment, etc.) within your Kubernetes cluster. Think of it as creating a temporary, private VPN connection to a single target inside the cluster. When you connect to the local port, your traffic is securely forwarded through the Kubernetes API server directly to the designated container port, making it appear as if the service is running locally on your workstation.

This mechanism leverages the Kubernetes API server as an intermediary. When you initiate a port-forward command, the kubectl client communicates with the API server, requesting it to open a connection to the specified pod. The API server then establishes a secure connection to the kubelet agent running on the node where the target pod resides. The kubelet, in turn, forwards the traffic to the actual container port. This multi-hop process ensures that the connection is secure, authenticated, and doesn't require any direct network access to the pod's underlying node or network.

The Anatomy of the Command: Basic Syntax

The most fundamental form of the kubectl port-forward command targets a specific pod:

kubectl port-forward <pod-name> <local-port>:<remote-port>

Let's break down each component:

• kubectl port-forward: The command itself, initiating the port forwarding operation.
• <pod-name>: The name of the Kubernetes pod you wish to connect to. This can be found using kubectl get pods.
• <local-port>: The port on your local machine that you want to use. You'll connect your local tools (browser, curl, database client) to this port.
• <remote-port>: The port inside the container within the specified pod that the service is listening on. This is crucial; if you specify the wrong remote port, the connection will fail.

Example 1: Forwarding a Simple Web Application

Imagine you have a pod named my-web-app-abcde running an Nginx server, listening on port 80. You want to access it from your local browser on port 8080.

1. Find your pod: bash kubectl get pods # Output might be: # my-web-app-abcde 1/1 Running 0 2h
2. Execute the port-forward command: bash kubectl port-forward my-web-app-abcde 8080:80 # Output: # Forwarding from 127.0.0.1:8080 -> 80 # Forwarding from [::1]:8080 -> 80

Now, if you open your web browser and navigate to http://localhost:8080, you will see the content served by the Nginx instance running inside the my-web-app-abcde pod in your Kubernetes cluster. Your local machine is effectively talking directly to that container. The command will continue running in your terminal, forwarding traffic, until you interrupt it (usually with Ctrl+C).

Beyond the Basics: Advanced Targeting and Multiple Forwards

While targeting a pod directly is powerful, kubectl port-forward offers more flexibility by allowing you to target other resource types. This is particularly useful when you don't care about a specific pod instance but rather any pod managed by a deployment or a service.

Targeting Services

Forwarding to a service allows kubectl to pick one of the pods backed by that service. This is often more convenient as pod names change frequently (e.g., during deployments or scaling).

kubectl port-forward service/<service-name> <local-port>:<remote-port>

Example 2: Forwarding to a Service

If you have a service named my-api-service that routes traffic to pods listening on port 8080, and you want to access it locally on port 9090:

1. Find your service: bash kubectl get services # Output might be: # my-api-service ClusterIP 10.96.0.100 <none> 8080/TCP 5m
2. Execute the port-forward command: bash kubectl port-forward service/my-api-service 9090:8080 # Output: # Forwarding from 127.0.0.1:9090 -> 8080 # Forwarding from [::1]:9090 -> 8080

Now, http://localhost:9090 will connect to one of the pods behind my-api-service. If that pod is recreated or scaled, kubectl will automatically pick another available pod, making your local connection more resilient to pod churn.

Targeting Deployments or ReplicaSets

You can also target higher-level controllers like Deployments or ReplicaSets. kubectl will then select a suitable pod managed by that controller.

kubectl port-forward deployment/<deployment-name> <local-port>:<remote-port>
kubectl port-forward replicaset/<replicaset-name> <local-port>:<remote-port>

This is generally less common than targeting pods or services directly but can be useful in specific scenarios where you want to interact with any instance of an application managed by a deployment without knowing the service name or individual pod names.

Forwarding Multiple Ports

Sometimes, an application might expose multiple ports, or you might need to access different services from the same pod. kubectl port-forward allows you to specify multiple port mappings in a single command.

kubectl port-forward <pod-name> <local-port-1>:<remote-port-1> <local-port-2>:<remote-port-2>

Example 3: Accessing a Web Server and its Admin Interface

If my-app-pod has a web server on port 80 and an admin interface on port 8001:

kubectl port-forward my-app-pod 8080:80 9001:8001
# Output:
# Forwarding from 127.0.0.1:8080 -> 80
# Forwarding from [::1]:8080 -> 80
# Forwarding from 127.0.0.1:9001 -> 8001
# Forwarding from [::1]:9001 -> 8001

Now http://localhost:8080 connects to the web server, and http://localhost:9001 connects to the admin interface.

Specifying the Namespace

By default, kubectl operates within the currently configured namespace. If your target pod or service is in a different namespace, you must specify it using the -n or --namespace flag.

kubectl port-forward -n <namespace-name> <pod-name> <local-port>:<remote-port>

Example 4: Forwarding from a Different Namespace

If my-db-pod is in the data-layer namespace and listens on port 5432 (PostgreSQL), and you want to connect locally on port 5432:

kubectl port-forward -n data-layer my-db-pod 5432:5432

This allows you to interact with services across different logical divisions within your cluster.

Practical Applications and Use Cases

The versatility of kubectl port-forward makes it invaluable across various development and operational scenarios.

1. Local Development and Testing

This is perhaps the most common use case. Developers often need to run parts of their application locally while connecting to services running in a Kubernetes cluster.

• Frontend Development: Develop a local frontend application that needs to communicate with a backend API running in the cluster. Instead of deploying the backend externally, port-forward allows your local frontend to connect directly.
• Database Access: Connect your local IDE's database client (e.g., DBeaver, DataGrip) to a database pod (PostgreSQL, MySQL, MongoDB) inside the cluster for schema inspection, data manipulation, or query testing.
• Message Queue Interaction: Interact with an internal message queue (Kafka, RabbitMQ) for producing or consuming messages from a local script or tool.

2. Debugging and Troubleshooting

When something goes wrong in the cluster, port-forward can be a lifesaver.

• Direct API Inspection: If an API endpoint within a microservice isn't behaving as expected, you can port-forward to that service and use curl or Postman from your local machine to send requests directly, bypassing any load balancers or ingress controllers. This helps isolate issues.
• Accessing Admin Consoles: Many applications (e.g., Redis, Kafka, databases) provide web-based or CLI-based admin consoles. If these aren't exposed externally, port-forward offers a quick way to access them for status checks, metric viewing, or configuration adjustments.
• Verifying Internal Connectivity: You can port-forward to a specific pod and then, from your local machine, attempt to connect to other internal services. This helps verify network policies or service discovery.

3. Secure Access to Internal Services

For services that should never be publicly exposed due to security or architectural reasons, port-forward provides a controlled, on-demand access mechanism.

• Internal Tools: Access internal monitoring dashboards, log aggregators, or specialized configuration UIs that are only meant for internal team members.
• Restricted Data Stores: Safely connect to sensitive data stores or internal APIs without opening firewall rules or setting up complex VPNs that might expose them more broadly. The connection is ephemeral and tied to your authenticated kubectl session.

APIPark is a high-performance AI gateway that allows you to securely access the most comprehensive LLM APIs globally on the APIPark platform, including OpenAI, Anthropic, Mistral, Llama2, Google Gemini, and more.Try APIPark now! 👇👇👇

Advanced Techniques and Best Practices

To truly master kubectl port-forward, understanding its nuances and employing effective strategies is key.

Running in the Background

The default behavior of kubectl port-forward is to run in the foreground, blocking your terminal. For continuous access or when running scripts, you'll often want it to run in the background.

Method 1: Using & (Linux/macOS)

kubectl port-forward my-web-app-abcde 8080:80 &

This will immediately return control to your terminal. You'll see the job ID and process ID. To bring it back to the foreground, use fg. To kill it, use kill <job-id> or kill <pid>.

Method 2: Using screen or tmux

These terminal multiplexers are excellent for managing multiple terminal sessions. You can start port-forward in a new screen or tmux session, detach from it, and later reattach if needed.

# Start a new tmux session
tmux new -s my-forward

# Inside the new tmux session:
kubectl port-forward my-web-app-abcde 8080:80

# Detach from tmux (Ctrl+B, then D)
# Later, to reattach:
tmux attach -t my-forward

Specifying the Address to Listen On

By default, kubectl port-forward listens on 127.0.0.1 (localhost) on your machine. This means only processes on your local machine can connect to it. If you need other devices on your local network to connect (e.g., a colleague's machine during pair programming, or a VM), you can specify 0.0.0.0 or a specific IP address using the --address flag.

kubectl port-forward --address 0.0.0.0 my-web-app-abcde 8080:80

Caution: Using 0.0.0.0 means anyone on your local network could potentially connect to your forwarded port. Be mindful of security when using this option, especially in untrusted networks.

Ignoring Local Port Conflicts

If your chosen local-port is already in use, kubectl port-forward will fail. You can explicitly tell it to use the local-port even if it's already in use (though this rarely works unless the existing process is non-binding). More often, you'll want to find an available port. A common practice is to use 0 for the local port, allowing the system to dynamically assign an available port.

kubectl port-forward my-web-app-abcde 0:80
# Output:
# Forwarding from 127.0.0.1:xxxxx -> 80  (where xxxxx is a dynamically assigned port)
# Forwarding from [::1]:xxxxx -> 80

This is incredibly useful in scripts or when you don't care about a specific local port number.

Using STDIN with port-forward

While port-forward primarily handles TCP connections, kubectl can also use STDIN and STDOUT for certain operations. For port-forward, this is generally not a direct interactive use case, but it underlies how kubectl itself establishes the connection. For most practical purposes, you'll be dealing with network clients (browsers, curl, database tools) connecting to the local port.

Best Practices

• Ephemeral Usage: kubectl port-forward is best for temporary, interactive access. It's not a solution for long-term, production-grade service exposure.
• Least Privilege: Only forward ports necessary for your current task. Close the connection when done.
• Monitor Your Forwards: Keep track of active port-forward sessions, especially if you run them in the background. Stray sessions can consume resources or, if --address 0.0.0.0 is used carelessly, pose a security risk. A simple ps aux | grep "kubectl port-forward" can help you find running processes.
• Documentation: If you're setting up a port-forward for a team, document the command and the purpose.

Security Considerations: When to Use, When to Avoid

While kubectl port-forward offers a secure tunnel, it's crucial to understand its security implications and limitations.

• Authentication & Authorization: The connection is authenticated against the Kubernetes API server using your kubectl context's credentials. This means only users authorized to access the cluster and the specific pod/service can initiate a port-forward. This is a significant security advantage over exposing services directly.
• Data Encryption: The tunnel itself is encrypted, typically using TLS, between your kubectl client and the API server, and between the API server and the kubelet. This protects your data in transit.
• Scope: port-forward provides access only from your local machine (or specified --address) to the specific target port. It doesn't open up arbitrary ports on the pod or cluster.
• Not for Production: This cannot be stressed enough. kubectl port-forward is not a production solution for exposing services. It lacks:
  • Scalability: It's a single point of connection from your machine.
  • High Availability: If your local machine crashes, the forward breaks.
  • Monitoring & Logging: It provides minimal insights into traffic or performance.
  • Advanced Routing & Load Balancing: No inherent capabilities for URL-based routing, path rewriting, or intelligent load balancing across multiple pods.
  • Sophisticated Security Features: No built-in Web Application Firewall (WAF), DDoS protection, rate limiting, or advanced authentication/authorization mechanisms (like OAuth2, JWT validation) for external consumers.

Table: kubectl port-forward vs. Production Service Exposure

Feature/Aspect	kubectl port-forward	Production Service Exposure (e.g., Ingress, LoadBalancer + API Gateway)
Purpose	Local development, debugging, temporary secure access	Persistent, scalable, secure external access for consumers
Target Audience	Developers, operators, internal teams	External users, client applications, other services
Scalability	Single client connection, not scalable	Highly scalable, supports thousands/millions of concurrent connections
Availability	Tied to local client's uptime	High availability, fault-tolerant infrastructure
Security	Authenticated tunnel, basic encryption, limited scope	Advanced authentication/authorization, WAF, DDoS, rate limiting
Load Balancing	None (targets one pod/service at a time)	Sophisticated load balancing, traffic routing, canary deployments
Visibility/Metrics	Minimal	Extensive logging, monitoring, analytics
Complexity	Simple command, easy to set up	Requires configuration of services, ingress, and potentially an API Gateway
Cost	Free (uses existing cluster resources)	Can incur costs for Load Balancers, Ingress Controllers, API Gateways

When you need to expose your services, particularly APIs, to external consumers in a robust, scalable, and secure manner, you move beyond kubectl port-forward. This is where dedicated solutions like Kubernetes Ingress Controllers (e.g., Nginx Ingress, Traefik) combined with a powerful API Gateway truly come into play.

Consider a scenario where you have several APIs, perhaps even some powered by AI models, that need to be consumed by external applications or partners. While port-forward might help you develop and test these APIs locally, it offers none of the enterprise-grade features required for production. This is precisely the domain of an API Gateway like ApiPark.

Introducing APIPark: Your Enterprise-Grade API Gateway

APIPark is an open-source AI gateway and API management platform designed to provide comprehensive lifecycle governance for both AI and REST services. Unlike the ad-hoc and temporary nature of kubectl port-forward, APIPark offers a persistent, highly performant, and secure solution for exposing and managing your APIs.

While kubectl port-forward gives you a direct, unmanaged channel to a single service, APIPark acts as a central control plane for all your APIs. It integrates quickly with over 100+ AI models, offering a unified API format for AI invocation, meaning you can encapsulate complex prompts into simple REST APIs. This is a stark contrast to port-forward, which merely opens a raw network tunnel.

For any organization building and deploying microservices or AI-driven applications, the features of a robust API Gateway like APIPark become critical:

• Unified API Format for AI Invocation: Standardizes requests across AI models, simplifying maintenance.
• End-to-End API Lifecycle Management: From design to publication, invocation, and decommission.
• Security & Access Control: Independent APIs and access permissions for each tenant, resource access requiring approval, and detailed logging for auditing. This level of granular control and auditing is simply not present in a port-forward scenario.
• Performance: Capable of over 20,000 TPS with cluster deployment, far exceeding what a local port-forward can offer.
• Data Analysis: Powerful tools to analyze historical call data for performance and trend monitoring.

In essence, if kubectl port-forward is your personal access key to a single door, APIPark is the entire secure, intelligent, and scalable lobby management system for your building, handling all external and internal traffic with sophisticated rules and oversight. For any serious API strategy, especially when involving AI, an API Gateway like APIPark provides the necessary foundation for efficiency, security, and scalability that port-forward is simply not designed for.

Troubleshooting Common kubectl port-forward Issues

Even with a solid understanding, you might encounter issues. Here's a breakdown of common problems and their solutions.

1. "Unable to listen on any of the requested ports"

This error indicates that the local-port you specified is already in use on your machine.

Solutions: * Choose a different local port: Try a higher-numbered port (e.g., 8080, 9000, 30000+). * Find and kill the conflicting process: * Linux/macOS: lsof -i :<local-port> will show which process is using the port. Then kill <PID>. * Windows: netstat -ano | findstr :<local-port> to find the PID, then taskkill /PID <PID> /F. * Let kubectl choose: Use 0 as the local port (kubectl port-forward <pod> 0:<remote-port>).

2. "Error from server (NotFound): pods \"\" not found"

This means kubectl cannot find the specified pod.

Solutions: * Check pod name: Double-check the spelling of the pod name. Use kubectl get pods to verify. * Check namespace: If the pod is in a different namespace, remember to use -n <namespace>. kubectl get pods -A lists pods across all namespaces. * Pod status: Ensure the pod is actually running and not in a pending, error, or terminated state.

3. "Error: dial tcp 10.x.x.x:yyyy: connect: connection refused" (from kubectl or your local client)

This indicates that kubectl successfully connected to the pod, but the application inside the pod is not listening on the specified remote-port, or a firewall within the pod is blocking the connection.

Solutions: * Check remote port: Verify the remote-port is correct. How do you know what port a container is listening on? * Inspect the pod's manifest: kubectl describe pod <pod-name>. Look for Containers -> Ports. * Check application configuration: Refer to your application's documentation or source code to confirm which port it binds to. * kubectl logs <pod-name> might show the application starting and listening on a specific port. * Verify application status: Ensure the application inside the container is actually running and healthy. kubectl logs <pod-name> can reveal startup errors. * Container firewall: Though rare in standard Docker images, confirm no internal firewall rules prevent the container from accepting connections on that port.

4. port-forward hangs or doesn't forward traffic

Solutions: * Firewall on local machine: Your operating system's firewall might be blocking connections to the local port. Temporarily disable it to test, or add an explicit rule to allow connections to the local port chosen for forwarding. * Network policy: If you have network policies enabled in your cluster, ensure they are not inadvertently blocking traffic between the kubelet and the target pod on the specific remote-port. * DNS issues within the cluster: While less common for direct port-forward, if your application inside the pod relies on internal DNS, ensure kube-dns or CoreDNS is healthy. * kubectl version: Ensure your kubectl client version is compatible with your cluster's API server version. Significant mismatches can lead to unexpected behavior.

5. port-forward exits immediately without an error message (or with a generic one)

This can be frustrating as it provides little diagnostic information.

Solutions: * --v=4 or --v=6 for verbose output: Run the command with a higher verbosity level to get more debugging details. bash kubectl port-forward --v=6 <pod-name> <local-port>:<remote-port> This can often reveal underlying connection issues or authentication failures. * Check kubelet logs: On the node where the pod is running, inspect the kubelet logs (journalctl -u kubelet) for any errors related to port-forward connections. * Cluster health: Ensure the Kubernetes cluster itself is healthy, especially the API server and kubelet components.

Alternatives and Complementary Tools

While kubectl port-forward is powerful, it's essential to know when other tools or Kubernetes resources are more appropriate.

1. kubectl proxy

kubectl proxy exposes the Kubernetes API server itself on a local port. This allows you to interact with the API directly from your browser or curl to access cluster resources, pods, logs, etc. It's different from port-forward because it's accessing the API server, not a specific service within a pod.

kubectl proxy --port=8001

Then you can access URLs like http://localhost:8001/api/v1/namespaces/default/pods/my-pod-name/proxy/ to interact with my-pod-name's internal web server. This is more cumbersome for direct application interaction but useful for programmatic access to the Kubernetes API.

2. Kubernetes Services (NodePort, LoadBalancer, Ingress)

These are the standard ways to expose services externally in a production environment.

• NodePort: Exposes a service on a static port on each node's IP address. Accessible from outside the cluster via <NodeIP>:<NodePort>. Suitable for development or small deployments where you control node IPs.
• LoadBalancer: Provisions an external cloud load balancer (e.g., AWS ELB, Google Cloud Load Balancer) that exposes the service on a public IP. Ideal for production traffic.
• Ingress: An API object that manages external access to services in a cluster, typically HTTP/S. It provides URL-based routing, SSL termination, and host-based virtual hosting. An Ingress Controller (like Nginx, Traefik, Istio Gateway) is required to fulfill the Ingress rules. This is the most flexible and common way to expose web APIs in production.

These methods are designed for persistent, scalable, and externally accessible service exposure, often integrated with API Gateways for advanced management.

3. VPN or SSH Tunnels

For more comprehensive network access to the entire cluster or underlying nodes, a traditional VPN (Virtual Private Network) into the cluster's network, or SSH tunneling to a bastion host within the network, might be used. These provide broader network access compared to port-forward's specific tunnel to a single port. While powerful, they are typically more complex to set up and manage.

4. Service Mesh (e.g., Istio, Linkerd)

A service mesh provides advanced traffic management, security, and observability features for microservices. While not a direct alternative to port-forward for local debugging, it can simplify complex routing and exposure scenarios, often including API Gateway functionalities, when services need to communicate securely and efficiently within or across clusters.

Conclusion: Empowering Your Kubernetes Workflow

kubectl port-forward is a cornerstone utility for anyone working with Kubernetes. It bridges the gap between your local development environment and the isolated world of containers within your cluster, offering a secure, temporary, and straightforward way to interact with internal services. From debugging a misbehaving API to inspecting a database or developing a frontend that relies on a cluster-resident backend, its applications are vast and varied.

However, true mastery lies not just in knowing how to use the command, but also in understanding its limitations and when to reach for more robust solutions. While port-forward excels at local, ephemeral access, it is fundamentally unsuitable for production API exposure. For the latter, dedicated API Gateway solutions like ApiPark provide the necessary scalability, security, and management capabilities to handle the complexities of external traffic and API lifecycle governance.

By integrating kubectl port-forward judiciously into your workflow and knowing when to leverage advanced Kubernetes exposure mechanisms and specialized API Gateway platforms, you can navigate the intricate landscape of containerized applications with unparalleled efficiency and confidence. Keep experimenting, keep learning, and let kubectl port-forward be a trusted ally in your Kubernetes journey.

---

Frequently Asked Questions (FAQ)

1. What is kubectl port-forward used for?

kubectl port-forward is primarily used by developers and operators to establish a secure, temporary tunnel from their local machine to a specific port on a pod or service inside a Kubernetes cluster. This allows local tools (like browsers, curl, database clients, IDEs) to directly interact with services running within the cluster, bypassing external exposure methods, which is ideal for local development, debugging, and accessing internal administrative interfaces.

2. Is kubectl port-forward secure enough for production traffic?

No, kubectl port-forward is not suitable for production traffic. While the tunnel itself is authenticated and encrypted, it's designed for single-client, temporary access and lacks the essential features required for production environments, such as scalability, high availability, load balancing, advanced security features (like WAF or DDoS protection), comprehensive monitoring, and detailed API management. For robust production API exposure, solutions like Kubernetes Ingress, Load Balancers, and dedicated API Gateway platforms like APIPark are necessary.

3. Can I forward multiple ports with a single kubectl port-forward command?

Yes, you can forward multiple ports in a single command. Simply list the local-port:remote-port pairs separated by spaces after the pod or service name. For example: kubectl port-forward my-pod 8080:80 9000:9001 would forward local port 8080 to remote port 80, and local port 9000 to remote port 9001 on the same pod.

4. What should I do if my local port is already in use when I try to run kubectl port-forward?

If your chosen local port is already in use, kubectl port-forward will fail with an error like "Unable to listen on any of the requested ports." You have a few options: a) Choose a different, unused local port. b) Identify and terminate the process currently using that port on your local machine. c) Use 0 as the local port (kubectl port-forward <resource> 0:<remote-port>) to let your system dynamically assign an available local port.

5. How does kubectl port-forward differ from an API Gateway like APIPark?

kubectl port-forward creates a direct, temporary, and unmanaged network tunnel for a single local client to a single service inside the cluster. It's a developer's debugging tool. An API Gateway like APIPark, on the other hand, is a comprehensive platform designed for managing, securing, and routing external access to multiple APIs (including AI models) in a scalable and robust production environment. APIPark offers features such as centralized authentication, lifecycle management, advanced routing, traffic shaping, monitoring, and detailed analytics, which are far beyond the scope and purpose of kubectl port-forward.

🚀You can securely and efficiently call the OpenAI API on APIPark in just two steps:

Step 1: Deploy the APIPark AI gateway in 5 minutes.

APIPark is developed based on Golang, offering strong product performance and low development and maintenance costs. You can deploy APIPark with a single command line.

curl -sSO https://download.apipark.com/install/quick-start.sh; bash quick-start.sh

In my experience, you can see the successful deployment interface within 5 to 10 minutes. Then, you can log in to APIPark using your account.

Step 2: Call the OpenAI API.