# Overview QuickPod is a distributed GPU and CPU marketplace for renting compute, publishing templates, operating host machines, and exposing workloads through higher-level product surfaces such as clusters and serverless endpoints. ## Start here Public console entry points: * [GPU Search](https://console.quickpod.io/) * [CPU Search](https://console.quickpod.io/cpu-pod-search) * [Templates](https://console.quickpod.io/templates) * [GPU Catalog](https://console.quickpod.io/gpu-types) * [Host Stores](https://console.quickpod.io/host-stores) * [System Status](https://console.quickpod.io/system-status) ## Current product areas QuickPod now includes more than basic pod search and templates. Major product areas covered in these docs: * search and launch workflows * public and community templates * authenticated settings, billing, notifications, and secrets * persistent storage and cloud sync * clusters and serverless publishing * host listings, host stores, occupancy, and contracts * public console landing pages used for discovery and sharing ## Who these docs are for * renters and users looking for affordable GPU or CPU compute * template authors who want repeatable launch definitions * hosts listing machines on the QuickPod marketplace * teams integrating QuickPod workflows into automation and APIs ## Support You can contact QuickPod through the website chat, Discord, or support email channels such as and . # Quick Start QuickPod can be used directly from the public console at [console.quickpod.io](https://console.quickpod.io/). Useful direct links: * [GPU Search](https://console.quickpod.io/) * [CPU Search](https://console.quickpod.io/cpu-pod-search) * [Templates](https://console.quickpod.io/templates) * [GPU Catalog](https://console.quickpod.io/gpu-types) * [Host Stores](https://console.quickpod.io/host-stores) * [Sign Up](https://console.quickpod.io/sign-up) * [Log In](https://console.quickpod.io/log-in) ## 1. Create an account and add credit Create an account first, then add prepaid credit from the console. QuickPod currently supports card checkout through Stripe and crypto checkout through the billing flow inside the console. If your balance reaches zero or below, QuickPod stops your pods automatically. Stopped pods can still accrue storage charges until you destroy them. ## 2. Prepare your access method QuickPod supports browser-based connection workflows and SSH-based access. For browser access, many templates expose a web UI, notebook UI, or terminal-ready endpoint directly. For SSH access, add your SSH public key in the authenticated console settings area before you create pods. If your workload needs a full SSH server, use a template that exposes SSH or clone a template and publish the right container port through the template's Docker options. ## 3. Choose a public or community template Open [Templates](https://console.quickpod.io/templates) to browse public templates and community templates, or create your own template after login. Templates define the image, launch mode, startup behavior, published ports, entrypoint behavior, and related readme content used during pod creation. ## 4. Search for an offer Use [GPU Search](https://console.quickpod.io/) or [CPU Search](https://console.quickpod.io/cpu-pod-search) to filter current offers by hardware count, GPU or CPU type, location, cost, duration, VRAM, occupied state, and other hardware traits. The search pages are public and can be used before login. ## 5. Set storage, secrets, and launch options During pod creation, choose the storage allocation carefully because storage cost continues while a pod exists. If your workload needs reusable credentials or mounted secrets, configure them from the authenticated console before launch and attach them to the pod during creation. If you need persistent shared data across launches, review the storage features described in [Storage & Cloud Sync](/console/storage-and-cloud-sync). ## 6. Create the pod Creating the pod reserves the selected offer and starts the workload from the chosen template. The pod then appears on the Pods page in the authenticated console. QuickPod shows startup and readiness state while the image is pulled, created, and initialized. ## 7. Connect and work Once the pod becomes ready, connect through the pod's exposed public routes, browser tools, or SSH depending on how the template was configured. Many public templates expose ports such as notebooks, dashboards, model APIs, or app UIs directly from the pod. ## 8. Stop or destroy when finished Stopping a pod prevents active compute charges, but storage still accrues while the pod exists. Destroy the pod when you no longer need the instance or its disk allocation. If you need persistence across sessions, move data into a volume or cloud-sync workflow first. # Introduction The QuickPod console is the main web interface for renting compute, managing workloads, browsing templates, operating host machines, and accessing public marketplace pages. Primary console URL: For an operation-by-operation decision guide, see [Console Operations FAQ](/console/operations-faq). ## Public pages you can open without logging in These routes are useful for public discovery, sharing, and documentation links: * [GPU Search](https://console.quickpod.io/) * [CPU Search](https://console.quickpod.io/cpu-pod-search) * [Templates](https://console.quickpod.io/templates) * [GPU Catalog](https://console.quickpod.io/gpu-types) * [Host Stores](https://console.quickpod.io/host-stores) * [System Status](https://console.quickpod.io/system-status) * [Clusters](https://console.quickpod.io/clusters) * [Serverless](https://console.quickpod.io/serverless) * [Storage](https://console.quickpod.io/storage) * [Refer & Earn](https://console.quickpod.io/refer) ## Core console areas ### Search and launch Use GPU Search or CPU Search to find rentable offers with live filters for hardware count, hardware type, VRAM, location, duration, price, occupied state, and related machine attributes. ### Templates The Templates page includes public templates, community templates, and your own templates once you log in. Templates define image, launch mode, startup behavior, Docker options, published ports, and readme content. ### Pods The authenticated Pods area is where you monitor pod readiness, connect, restart, stop, or destroy workloads after launch. ### Storage The Storage area covers persistent volumes and cloud sync workflows for moving data between QuickPod volumes and supported providers. ### Clusters and serverless Clusters let you run multiple replicas of a template under one logical deployment, and Serverless lets you publish a cluster service through a managed invoke URL. ### Settings and security The Settings area now includes billing, invoices, two-factor authentication, secure API keys, user profile settings, notifications, and reusable secrets. ### Hosting mode Host accounts see additional hosting routes for listing machines, adjusting offer pricing, monitoring occupancy, reviewing contracts, and managing host storefronts. For a page-by-page public route reference, see [Public Pages](/console/public-pages). # Console Operations FAQ This FAQ explains what each major user-facing console operation is for, when to use it, and when to choose a different workflow. It is grounded in the current QuickPod console behavior across Search, Pods, Templates, Storage, Clusters, Serverless, Secrets, and Settings. ## Scope This page focuses on user-facing console operations, not internal admin tools or host-only listing controls. Related docs: * [Introduction](/console/introduction) * [Search & Launch](/console/search-and-launch) * [Pods](/console/pods) * [Templates](/console/templates) * [Storage & Cloud Sync](/console/storage-and-cloud-sync) * [Clusters](/console/clusters) * [Serverless](/console/serverless) * [Secrets](/console/secrets) * [Settings](/console/settings) ## Search and launch ### Which search page should I use? Use [GPU Search](https://console.quickpod.io/) when your workload needs one or more GPUs. Use [CPU Search](https://console.quickpod.io/cpu-pod-search) when the workload is CPU-only or you want lower-cost general compute. ### What does creating a pod let me configure? The current create flow lets you evaluate and set: * the offer you are renting * the template you will launch * a pod name * disk size * an optional coupon * an optional persistent volume * optional secret bindings This means pod creation is not only a hardware choice. It is the point where compute, image, storage, and secret mounting are combined into one launch request. ### When should I change filters instead of launching the first matching offer? Change filters first when cost, location, duration limits, VRAM, or reliability matter more than getting any immediate capacity. The search console is meant to narrow to a suitable offer before you commit to a launch. ### Should I pick a template before clicking Create Pod? Yes. In QuickPod, the template is part of the launch design, not an afterthought. It determines image path, startup behavior, launch mode, published ports, and readme guidance. If you are not sure which template to use, review [Templates](/console/templates) first. ### How should I evaluate launch-time storage choices? Use pod disk size when the data only needs to live with that pod. Use a volume when the data should survive beyond one pod lifecycle, be reused by later launches, or participate in cloud sync workflows. ### Search and launch quick reference | Operation | Use it when | Avoid it when | Notes | | ------------------------ | ----------------------------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Search GPU offers | You need GPU-backed compute | The workload is CPU-only | Filters, price, region, duration, and reliability matter before launch | | Search CPU offers | You need CPU-only compute or lower-cost runtime | You need CUDA or GPU VRAM | CPU templates and CPU offers are separate from GPU launch flows | | Create Pod | You are ready to rent a specific offer | You are still comparing hardware, templates, or storage strategy | The launch modal is where template, disk, volume, secrets, and coupon are combined | | Attach volume at launch | You need persistent data that outlives one pod | The workload is disposable | Volumes are better than leaving stopped pods around only to preserve disk data | | Attach secrets at launch | The container needs credentials or token files | The value is safe to keep in plain text, which is uncommon | Secrets are mounted read-only and can optionally populate a \*\_FILE environment variable | ## Pods ### What is the Pods page for after launch? The [Pods](/console/pods) page is the operational control center after creation. It is where you monitor readiness, connect, inspect logs, rename the workload, and run lifecycle actions such as start, stop, restart, and destroy. ### What is the practical difference between stop and destroy? Stop pauses the workload but keeps the pod and its storage footprint. Destroy removes the pod entirely. Use stop when you expect to resume the workload later and want to keep the pod around. Use destroy when the workload is finished and you no longer need the pod or its attached pod-local storage. ### Why does stop not eliminate all cost? Because stopped pods can still retain storage. The console distinguishes active running spend from stopped-storage spend specifically so you can see that keeping a stopped pod is not free. ### When should I use start? Use start when a previously stopped pod should resume. Start is a recovery or continuation action, not a substitute for launch. If you need different hardware, different ports, or a different base template, create a new pod instead. ### When should I use restart? Use restart when the running container needs a clean process restart but you do not want to destroy and recreate the whole pod. Restart is appropriate for application-level recovery, not for changing the pod's core launch configuration. ### What are logs and connect for? Use logs to inspect recent runtime output and troubleshoot container startup or application issues. Use connect when the pod is ready and you need interactive access or the console-provided connection details. ### Can I rename a pod? Yes. Renaming is useful for organization and does not change the underlying rented hardware or template definition. ### Pod operations quick reference | Operation | Use it when | Avoid it when | Notes | | --------- | --------------------------------------------------- | ------------------------------------------------------------------- | --------------------------------------------------------------------- | | Connect | The pod is ready and you need interactive access | The pod is still provisioning or connection details are not ready | Connection depends on the pod exposing the right route or access mode | | View logs | You need startup or runtime output | You need to change template settings, not inspect runtime behavior | Logs are usually the first place to check a failed startup | | Rename | You want clearer organization in the Pods list | You expect it to change the workload internals | Rename is cosmetic and organizational | | Stop | You want to pause compute and possibly resume later | You want to eliminate the pod completely | Storage cost can remain after stop | | Start | You want to resume a stopped pod | You need a new hardware choice or a different base config | Start resumes the existing pod rather than creating a new one | | Restart | You want to recycle the running container cleanly | You need to change launch-time inputs like template, disk, or offer | Restart is best for runtime recovery | | Destroy | You are finished with the pod | You still need the pod or its pod-local disk state | Destroy is the terminal cleanup action | ## Templates ### What is the difference between select, create, edit, and clone? Select marks a template as the one you want to use in launch flows. Create makes a brand-new template in your account. Edit changes one of your existing templates. Clone copies another template into your account so you can customize it without editing the original source template. ### When should I clone instead of create from scratch? Clone when a public or community template is already close to what you need. This is usually the fastest way to keep known-good ports, commands, and image defaults while making only your required changes. Create from scratch when the workload, image, or launch behavior is materially different from existing templates. ### What should I edit in a template versus at pod launch? Edit the template when the setting is part of the reusable workload definition, such as: * image path * Docker options and published ports * launch mode * entrypoint behavior * on-start script * recommended disk size * template readme Change values at pod launch when the setting is pod-specific, such as the chosen offer, final pod name, coupon, attached volume, or selected secrets. ### When should I use a private registry template? Use private registry settings when the image is not publicly pullable. Put registry credentials in the template's dedicated private registry fields instead of embedding them in commands or documentation text. ### What does sharing with the community mean? Community sharing makes your template discoverable to other users for cloning and reuse. Use it for general-purpose or reusable workloads, not for account-specific or secret-dependent templates. ### Should I delete a template? Delete a template when it is obsolete, duplicated, or no longer safe to present as a launch option. Do not delete a template solely because one pod created from it is no longer needed. Pods and templates are separate lifecycle objects. ### Template operations quick reference | Operation | Use it when | Avoid it when | Notes | | -------------------- | ----------------------------------------------------------------- | --------------------------------------------------------------------- | ------------------------------------------------------------- | | Select | You want this template to be the default choice for launch flows | You only want to inspect it | Select improves launch speed but does not modify the template | | Create template | You need a reusable workload definition | A public or community template already matches closely | Best for repeated launches and consistent settings | | Edit template | You own the template and need to change reusable behavior | You need a one-off pod-specific override | Edit changes the reusable definition for future launches | | Clone template | You want to reuse an existing public or community template safely | You need to modify the original publisher's template directly | Clone creates your own copy | | Share with community | The template is general, reusable, and safe to publish | The template depends on private assumptions or account-specific setup | Community sharing improves discoverability | | Delete template | The template is obsolete or duplicated | The only issue is a single bad pod launch | Delete removes it from your template library | ## Storage and cloud sync ### When should I create a volume? Create a volume when data needs to outlive one pod or be reused by future pods, clusters, or sync jobs. Volumes are the correct persistence layer for reusable data. ### When is cloud sync better than manually copying files? Cloud sync is better when you need repeatable transfers between QuickPod storage and a provider such as Amazon S3, Backblaze B2, Dropbox, or Google Drive. It is especially useful for scheduled imports, exports, backups, and ongoing data refresh. ### What is the difference between manual-only and recurring schedule? Manual-only means the sync target exists but runs only when you start a job. Recurring schedule means QuickPod will run sync jobs automatically using the configured cadence and timezone. ### Should I save cloud credentials as reusable secrets? Yes. Reusable secret-backed credentials are better than repeatedly pasting provider credentials into setup flows. That keeps the sync configuration cleaner and reduces credential sprawl. ### Storage operations quick reference | Operation | Use it when | Avoid it when | Notes | | ------------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------- | --------------------------------------------------------------------- | | Create volume | You need persistent storage independent of one pod | The workload is disposable and temporary | Volumes are reusable across later workflows | | Delete volume | The data is no longer needed | The volume is still attached to an active workflow | Treat deletion as data lifecycle cleanup | | Create cloud sync target | You need repeatable movement between a volume and a cloud provider | You only need a one-time local copy | Targets store provider, direction, remote path, and schedule behavior | | Run manual sync | You want an on-demand transfer | You need unattended recurring movement | Manual runs are safer while validating a new target | | Enable recurring schedule | You need automated sync cadence | The data movement should stay operator-controlled | Timezone and cadence matter for predictable job timing | | Edit cloud sync target | Provider settings or schedule rules changed | The existing target is correct and only needs a one-off run | Edit is better than recreating when the relationship stays the same | ## Clusters ### When should I create a cluster instead of a single pod? Create a cluster when you want multiple replicas, service routing, rolling redeploy behavior, or autoscaling and schedule controls. Use a single pod when you only need one isolated runtime and do not need cluster-level service management. ### What do the main cluster actions mean? Create cluster starts a multi-replica deployment based on a chosen template and offer strategy. Start and stop control the cluster-managed replicas as a group. Scale changes desired replica count. Rolling redeploy replaces replicas gradually while respecting readiness gates. Delete cluster removes the cluster and its managed replicas. ### What should I use rolling redeploy for? Use rolling redeploy when the workload definition or release state has changed and you want the cluster to refresh replicas safely instead of dropping everything at once. ### What are services for on a cluster? Cluster services define how traffic reaches ready replicas. They also carry protocol, context path, and health-check behavior that higher-level features such as Serverless can build on. ### How should I think about autoscaling, scheduled scaling, and placement? Use autoscaling for load-responsive replica changes. Use scheduled scaling for predictable business-hour or batch windows. Use placement rules when topology, isolation, geography, or machine-type preferences matter. Tighter placement improves control but can reduce compatible capacity. ### What do cluster storage modes affect? Storage mode controls whether replicas have no cluster volume, a shared volume, or shard-specific volumes. This choice changes how data is shared, isolated, and scaled across replicas. ### Cluster operations quick reference | Operation | Use it when | Avoid it when | Notes | | ------------------- | ------------------------------------------------------------------------- | ---------------------------------------------------------- | ----------------------------------------------------------- | | Create cluster | You need a managed multi-replica workload | One pod is sufficient | Clusters add service, rollout, scaling, and policy surfaces | | Start cluster | The cluster is stopped and should resume | You actually need more replicas or a new template revision | Start resumes the current cluster state | | Stop cluster | You need to pause the whole deployment | You only need to remove one replica or service definition | Stop affects all cluster-managed replicas | | Scale cluster | You need more or fewer replicas | The main need is a new release rollout | Scale changes capacity, not workload definition | | Rolling redeploy | You need to refresh replicas safely | The cluster is only paused and should simply be started | Readiness-gated rollout reduces abrupt downtime | | Add or edit service | You need a stable service endpoint or health-aware routing | You only need direct pod access | Services are the routing layer for clusters and serverless | | Edit policy | You need to change autoscaling, schedules, rollout, or placement behavior | Nothing about control policy has changed | Placement strictness can reduce available capacity | | Delete cluster | The deployment is permanently no longer needed | You only want to pause or redeploy | Delete destroys the cluster-managed workload | ## Serverless ### What has to exist before I create a serverless endpoint? You need a cluster and at least one cluster service first. Serverless publishes that cluster service behind a managed invoke path. ### What is the difference between hot service and warm service? The hot service is the main active backend for requests. The warm service is an optional secondary service used in the current serverless model where the endpoint needs both primary and standby-style routing behavior. ### When should I edit an endpoint versus recreate it? Edit when the endpoint still represents the same product surface and you only need to adjust slug, auth mode, timeout, active state, pricing, or service binding. Recreate only when the endpoint concept itself should be replaced or removed. ### What does active versus inactive do? Active keeps the endpoint available for normal invoke traffic. Inactive keeps the definition but disables normal use until you reactivate it. ### When should I inspect serverless logs? Inspect logs when debugging requests, checking status codes, verifying routing behavior, or confirming that endpoint settings are producing the intended API behavior. ### Serverless operations quick reference | Operation | Use it when | Avoid it when | Notes | | ---------------------------------- | ----------------------------------------------------------------- | ------------------------------------------- | ----------------------------------------------------------------- | | Create endpoint | You want to expose a cluster service through a managed invoke URL | No cluster service exists yet | Serverless depends on cluster service definitions | | Edit endpoint | Slug, auth, timeout, pricing, or service mapping needs adjustment | The endpoint should be retired entirely | Edit preserves the endpoint identity while changing configuration | | Toggle active state | You want to temporarily disable or re-enable traffic | The endpoint should be deleted permanently | Inactive keeps configuration without serving normally | | Review invoke URL and curl example | You need integration-ready request details | You are not ready to expose the service yet | The console generates practical invocation examples | | Review logs | You need request and response visibility | You need runtime container logs instead | Endpoint logs are request-centric rather than container-centric | | Delete endpoint | The API surface is no longer needed | A temporary pause is enough | Delete is irreversible cleanup | ## Secrets ### Why should I create a secret instead of storing the value in a template? Because templates are reusable workload definitions and should not contain plaintext credentials. Secrets keep sensitive values out of template text, commands, and screenshots. ### How are secrets exposed inside the workload? Secrets are mounted read-only under `/run/secrets`. If you set an environment-variable file mapping during attachment, QuickPod can also export a `*_FILE` style variable pointing to that mounted path. ### When should I revoke a secret? Revoke when the credential is no longer trusted, no longer needed, or has been rotated elsewhere. Do not revoke casually if active workflows still depend on it. Future pod creates or resets that reference the revoked secret can fail. ### Secret operations quick reference | Operation | Use it when | Avoid it when | Notes | | -------------------- | ----------------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------ | | Create secret | A workload or sync target needs sensitive data | The value can safely live in plain text, which is rare | Plaintext is shown once and then cleared from the visible UI | | Attach secret to pod | The container needs file-backed credentials or tokens | The workload has no secret requirement | Secret bindings are safer than embedding values in commands | | Revoke secret | The value is obsolete, rotated, or compromised | Existing workflows still rely on it and have not been updated | Revoke blocks future reuse | ## Settings, billing, security, and notifications ### Where do account-level operations live? Account profile, billing, invoices, security controls, reusable secrets, SSH public keys, notifications, and secure API keys are centered in [Settings](/console/settings) and related authenticated routes. ### When should I create a secure API key? Create one when an external script, CI job, or integration needs authenticated API access without using your browser session directly. ### What matters most about secure API keys? The plaintext secret is shown once. Copy it immediately and store it securely. If it is lost or exposed, revoke it and create a new key rather than expecting the console to reveal the old secret again. ### When should I revoke an API key? Revoke a key when the integration is retired, the scope is no longer appropriate, or you suspect exposure. ### Why should I use notifications instead of checking every page manually? Notifications are the cross-product alert surface for pods, storage, hosting signals, billing, and system events. They reduce the need to poll each page for changes. ### Settings and security quick reference | Operation | Use it when | Avoid it when | Notes | | ---------------------------- | ------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------- | | Add credit or manage billing | You need to fund or review account usage | You only need workload runtime diagnostics | Billing is separate from operational troubleshooting | | Configure 2FA | You want stronger account protection | You are looking for API integration credentials | 2FA protects sign-in, not API automation | | Add SSH public key | You plan to use SSH-based access patterns | The workload does not require SSH | Key management belongs in Settings, not templates | | Create secure API key | Automation needs authenticated API access | A browser session is sufficient and no automation exists | Secrets are shown once only | | Revoke secure API key | The key is stale or exposed | The integration still depends on it and has not been updated | Revocation is the safe rotation path | | Review notifications | You need cross-product activity visibility | You need detailed runtime logs for one workload | Notifications summarize events; they do not replace full logs | ## Recommended workflow patterns ### I want to launch quickly but keep things clean later 1. Pick the right search page. 2. Select or clone a suitable template first. 3. Create the pod with the right disk, volume, and secrets. 4. Use Pods for runtime actions. 5. Destroy finished workloads instead of accumulating stopped pods. ### I want repeatable production-style behavior 1. Create or clone a stable template. 2. Move credentials into Secrets. 3. Use volumes for persistent data. 4. Move multi-replica services into Clusters. 5. Publish stable invoke paths through Serverless when external callers need an API surface. ### I want to reduce avoidable mistakes 1. Do not put credentials into template text or startup commands. 2. Do not use stop when you really mean destroy. 3. Do not use restart when the issue is actually a bad template or wrong ports. 4. Do not use a single pod when you actually need service routing and controlled rollout. 5. Do not revoke secrets or API keys before dependent workloads are updated. # Search & Launch QuickPod's public search pages are the main entry point for renting compute. Direct links: * [GPU Search](https://console.quickpod.io/) * [CPU Search](https://console.quickpod.io/cpu-pod-search) * [GPU Catalog](https://console.quickpod.io/gpu-types) ## What the search pages do The search console lists currently rentable offers from QuickPod hosts. Each offer represents a rentable slice of compute capacity with its own price, hardware details, duration rules, and port range. ## Current filter categories The current search experience includes filters and sorting for: * GPU or CPU search mode * hardware count * hardware type * sort order * max duration * max hourly cost * minimum VRAM where relevant * region selection * occupied offers visibility * privileged-only visibility These filters are persisted in the browser so the console can restore your last-used search preferences. ## Template-aware launch flow Search and launch is closely tied to templates. Before creating a pod, select a matching template for the workload you want to run. The selected template influences image path, launch mode, exposed routes, and user experience after the pod starts. Use [Templates](https://console.quickpod.io/templates) to browse available templates before launching. ## Typical workflow 1. Open GPU Search or CPU Search. 2. Filter to the hardware profile, cost, and location you want. 3. Pick a template that matches your workload. 4. Set storage size and any runtime-specific options. 5. Create the pod. 6. Open the authenticated Pods page to monitor readiness and connect. ## Related public pages * [Templates](https://console.quickpod.io/templates) * [GPU Catalog](https://console.quickpod.io/gpu-types) * [Host Stores](https://console.quickpod.io/host-stores) ## Notes If you are comparing a GPU family before renting, start from the public GPU catalog. If you already know the hardware family, the search pages are the fastest way to filter to live rentable offers. # Pods Authenticated route: `/pods` Public entry points that lead into pod creation: * [GPU Search](https://console.quickpod.io/) * [CPU Search](https://console.quickpod.io/cpu-pod-search) * [Templates](https://console.quickpod.io/templates) ## What the Pods page does The Pods page is the authenticated control center for workloads after they are launched. ## Current pod management capabilities The current console surface includes: * GPU and CPU pod views * cached pod list updates * running spend summary * stopped-storage spend summary * connect and logs workflows * start, stop, restart, and destroy actions * state-aware readiness and lifecycle visibility ## Cost visibility The current pod page distinguishes between: * running spend per hour for active pods * storage spend per hour for stopped pods that still exist This distinction matters because stopping a pod does not remove storage cost. ## Typical workflow 1. Launch from search. 2. Open Pods after creation. 3. Wait for the workload to become ready. 4. Connect, monitor, or inspect logs. 5. Stop when temporarily finished, or destroy when the workload and disk are no longer needed. ## Related docs * [Search & Launch](/console/search-and-launch) * [Templates](/console/templates) * [Storage & Cloud Sync](/console/storage-and-cloud-sync) # Settings The authenticated Settings area is now the control center for account configuration, billing, security, invoices, secure API keys, and secrets. ## What lives in Settings ### Account profile Manage basic account profile fields, billing details, avatar, and payout-related information that belongs to your user account. ### Billing and invoices Add credit, review invoice history, and manage linked payment methods. Billing behavior is covered in more detail in [Billing](/console/billing). ### Security and two-factor authentication QuickPod supports stronger account protection through email and authenticator-based two-factor flows inside the settings surface. ### Secure API keys QuickPod supports secure API keys for automation and integrations. These are intended for scripted workflows rather than sharing your main session credentials. ### SSH public key Add your SSH public key before creating pods if you want SSH-based access for workloads that expose or run SSH. ### Reusable secrets Manage reusable secret values that can later be attached to pods or storage workflows without hardcoding values into templates. ### Notifications Review notification history and configure category preferences for platform events such as pods, storage, hosting, billing, and system alerts. ## Related routes These routes require authentication, but they are part of the current console experience that older docs often miss: * `/settings` * `/notifications` * `/secrets` Direct public login links: * [Log In](https://console.quickpod.io/log-in) * [Sign Up](https://console.quickpod.io/sign-up) # Templates Templates define how QuickPod launches a workload. Direct link: ## Template sources The current Templates page includes: * Public templates maintained for common QuickPod workflows * Community templates shared by users * Your own templates after login ## What a template contains A template can define: * image path * template name and description * launch mode * Docker options, including published ports * Docker run options and entry behavior * CLI command or startup behavior * disk recommendation * readme content shown in the console * template type used for GPU or CPU launch flows ## Common workflows ### Browse a public template Use the public Templates page to inspect a template before login. ### Clone a public or community template After login, clone a template into your account if you want to modify ports, startup commands, environment variables, or related launch settings. ### Create your own template Authenticated users can create a brand-new template for internal use or publishing to the community. ### Share with the community Templates can be marked for community sharing so other users can discover and clone them. ## Template types and launch pages GPU templates are used from [GPU Search](https://console.quickpod.io/) and CPU templates are used from [CPU Search](https://console.quickpod.io/cpu-pod-search). ## Notes on ports If your workload needs a web UI or API, publish the container port in the template's Docker options. Public template docs should make expected ports clear so users know what endpoint they are creating. # Billing QuickPod uses prepaid account credit. You add credit first, then active workloads consume that balance over time. ## Current payment behavior QuickPod's current console billing flow supports card checkout through Stripe and crypto-oriented billing flows exposed through the billing experience in Settings. The billing area in the console also exposes invoice history and payment-link or payment-method related controls. ## How charges work QuickPod separates compute cost from storage cost. * Running pods accrue active compute cost plus storage cost. * Stopped pods stop compute cost but continue to accrue storage cost while they still exist. * Destroyed pods stop both compute and storage cost for that pod. * Persistent storage and sync workflows can have their own associated costs depending on how you size or use them. Internet bandwidth usage is charged at $4 per TB. This bandwidth pricing is set by the platform and is subject to change. ## What happens when your balance reaches zero QuickPod does not immediately destroy your workloads and data when your balance reaches zero. Instead, pods are stopped automatically so you can still recover data or add more credit. Storage charges may continue while the stopped pod still exists. ## Billing guidance * Destroy pods you no longer need. * Use volumes or cloud sync if you need persistence without leaving expensive pod disks running indefinitely. * Review invoices and balance inside the authenticated settings experience regularly. ## Related console routes * Authenticated billing area: `/settings` * Public sign in: * Public sign up: # Storage & Cloud Sync Authenticated route: `/storage` Public route for the console page itself: ## What storage covers QuickPod storage is no longer just the pod disk size slider during launch. The current product includes persistent volumes and cloud sync workflows. ## Current storage areas ### Volumes Create and manage persistent volumes that can survive independently from an individual pod lifecycle. ### Cloud Sync Cloud Sync lets you move data between a QuickPod volume and supported cloud storage providers. Current provider coverage in the console includes: * Amazon S3 * Backblaze B2 * Dropbox * Google Drive ## Current cloud sync capabilities The cloud sync surface supports: * push and pull direction control * provider-specific remote settings * reusable credentials through secrets * manual sync jobs * scheduled sync jobs * schedule timezone and cadence settings * job history and sync target management ## When to use storage features Use a volume when you want persistence independent of a single pod. Use cloud sync when you need to move data between QuickPod and a storage provider you already use. ## Related routes * Authenticated storage management: `/storage` * Authenticated secrets management: `/secrets` * Public console page: ## Practical guidance If the workload is disposable, pod-local storage may be enough. If the workload needs repeatable datasets, backups, or shared persistence across launches, use volumes and cloud sync instead of leaving stopped pods around only for their disks. # Clusters Public route: ## What clusters are QuickPod clusters let you run multiple replicas of a workload under one logical deployment instead of managing each pod separately. ## Current cluster concepts The current cluster surface includes: * cluster creation from templates * replica management * start and stop controls * rolling redeploy behavior * scale workflows * replica health visibility * cluster storage modes * cluster services and connect behavior ## Storage modes Clusters can be configured with no cluster volume, shared storage, or sharded storage depending on how the workload should persist data. ## Why use clusters Clusters are useful when you want a repeatable deployment model for: * multi-replica inference or API backends * services you want to expose through a stable service layer * workloads that need shared or predictable storage behavior across replicas ## Related public and authenticated routes * Public cluster landing page: * Cluster detail after login: `/clusters/:id` * Serverless publishing on top of cluster services: `/serverless` ## Notes QuickPod's cluster features are implemented in QuickPod's own control plane and routing model. They should be understood in QuickPod terms rather than generic Kubernetes terminology. # Serverless Public route: ## What serverless means in QuickPod QuickPod serverless publishes a cluster service behind a managed invoke path so users can call it like an API. ## Current serverless endpoint fields The current serverless experience includes: * endpoint name * slug * hot service binding * optional warm service binding * auth mode * auth token when token-based access is used * request timeout * base price per call * price per 100ms * active or inactive state * request logs * generated invoke URL and curl example ## Typical workflow 1. Create a cluster. 2. Define a cluster service that targets the workload port. 3. Open the Serverless area. 4. Create a serverless endpoint that points to the cluster service. 5. Share or integrate against the invoke URL. ## Why serverless is useful Serverless is useful when you want a stable HTTP entry point for an inference backend, tool endpoint, or service workload without sharing raw pod coordinates. ## Related routes * Public serverless landing page: * Serverless create route after login: `/serverless/create` * Cluster management: `/clusters` ## API note QuickPod serverless invoke paths are public product APIs, not just internal console implementation details. They deserve separate API documentation if you are building external integrations. # Notifications Authenticated route: `/notifications` Login page: ## What notifications cover QuickPod notifications provide an account-level feed of operational, billing, and platform events. ## Current notification categories The console currently exposes category-level preferences for: * billing * hosting telemetry * pods * storage * cloud sync * clusters * system * admin ## Current capabilities The Notifications page lets you: * read recent notifications * see unread counts * mark individual notifications as read * mark all notifications as read * mute or unmute categories ## Why this matters Notifications are now part of the core QuickPod operations experience for both renters and hosts. Older docs that only discussed email or support channels are missing an important part of the modern console. # Secrets Authenticated route: `/secrets` Login page: ## What secrets are QuickPod secrets are reusable sensitive values stored in your account for later use by pods, storage workflows, or automation. ## Current secrets page behavior The current Secrets page is focused on reusable pod secrets for runtime configuration and automation. ## Why use secrets Use secrets when you need to avoid hardcoding values into: * templates * manual runtime commands * cloud sync setup * pod configuration flows ## Related docs * [Settings](/console/settings) * [Storage & Cloud Sync](/console/storage-and-cloud-sync) * [API Documentation](/api-and-cli/api-documentation) # Public Pages These QuickPod console pages can be opened directly without logging in and are suitable for public documentation, sharing, and external linking. ## Search and discovery * [GPU Search](https://console.quickpod.io/) * [CPU Search](https://console.quickpod.io/cpu-pod-search) * [Templates](https://console.quickpod.io/templates) * [GPU Catalog](https://console.quickpod.io/gpu-types) ## Marketplace and host discovery * [Host Stores Directory](https://console.quickpod.io/host-stores) * Host storefront pattern: `https://console.quickpod.io/store/` ## Product landing pages inside the console These routes currently act as public product surfaces when a visitor is not authenticated: * [Clusters](https://console.quickpod.io/clusters) * [Serverless](https://console.quickpod.io/serverless) * [Storage](https://console.quickpod.io/storage) * [System Status](https://console.quickpod.io/system-status) * [Refer & Earn](https://console.quickpod.io/refer) ## Authentication pages * [Log In](https://console.quickpod.io/log-in) * [Sign Up](https://console.quickpod.io/sign-up) ## How to use these links in docs Use direct public links in documentation when: * the page is useful before login * you are documenting public discovery or marketplace browsing * you want users to jump directly into the correct console surface Avoid linking authenticated internal routes as public documentation links unless the page is specifically being described as login-required. # Environment Variables When you create a template and specify the startup command, it is sometimes necessary to know the port mappings, public ip address etc. The following environment variables are available to use in your startup scripts and inside your pod. $PUBLIC\_IPADDR Public IP address of the machine hosting your pod $SSH\_PUBLIC\_KEY Your ssh public key $CONTAINER\_LABEL The label of the container/Pod, this is also the POD api key $GPU\_COUNT The number of GPUs in your Pod $QUICKPOD\_PORT\_XXXX The externally mapped port for your specified internal port XXXX e.g. you mapped with -p 3000:3000 and quickpod mapped the machine port to 41000 then $QUICKPOD\_PORT\_3000 will give you the value 41000. This is dynamic mapping. SYMMETRICAL PORTS are ports >= 70000 provided in -p 70000:70000, they map the same internal and external ports and are available through the variable $QUICKPOD\_PORT\_XXXX (e.g. $QUICKPOD\_PORT\_70000) # Overview QuickPod hosts supply GPU or CPU capacity to the QuickPod marketplace and manage their listings from the hosting side of the console. Important public and host-related routes: * Public marketplace search: * Public host directory: * Host console area after login: `/hosting` * Host occupancy analytics after login: `/occupancy` * Host contracts after login: `/contracts` * Host storefront management after login: `/my-store` ## What hosts manage today The current hosting experience goes beyond simple machine listing. Hosts now manage: * machine health and listing state * GPU and CPU offer pricing * minimum GPU grouping and max duration rules * privileged access eligibility * occupancy and reliability visibility * payout setup and payout history * contract visibility * public host storefront branding and sharing ## Core host responsibilities Hosts are still responsible for machine setup, networking, system reliability, thermal stability, driver health, and predictable uptime. QuickPod expects listed machines to have working open ports, stable networking, and healthy hardware. ## Listings and contracts An offer is the rentable unit presented to users in the public search console. When a user launches on your offer, that activity becomes part of your host-side contract and revenue history. Duration, pricing, and hardware grouping influence how your machine appears in the search marketplace. ## Newer host-facing surfaces the old docs missed ### Occupancy analytics Hosts can inspect occupancy and usage trends from the dedicated occupancy route. ### Contracts Hosts can review contract history and cost-related details from the contracts route. ### Earnings and payouts Hosts can configure payout providers and track payout history from the earnings and billing-related host surfaces. ### Host stores Hosts can publish a branded storefront and share public links to their offers. See [Host Stores & Analytics](/hosting/host-stores-and-analytics) for the newer host experience. ## Maintenance guidance Avoid disruptive maintenance while customer workloads are active. Delisting prevents new contracts, but existing workloads and contract expectations still matter until they expire or are terminated cleanly. # Machine Setup To add a machine GPU or CPU you need to install Ubuntu 22.04 on the machine and prepare a range of open ports, choose a standard installation of Ubuntu 22.04 desktop or server version. currently we do not support any other version of ubuntu. Windows and ubuntu 23.04 support will be added later. To install quickpod software on your machine and connect it to your account switch to root account with command sudo su - and run the following command. Copy {% code overflow="wrap" %} ``` wget -O install.bin https://data.quickpod.io/install.bin && chmod 755 ./install.bin && ./install.bin YOUR_API_KEY ``` {% endcode %} The installer will ask for your open port range, if you made a mistake you can manually edit the following file to update your port range /var/lib/quickpod/machine\_open\_port\_range. After a successful installation please visit the machine page GPU Machines if machine has GPUs or CPU Machines to list your machine and set prices for GPU, CPU, storage and duration etc. If you face difficulties please use live chat or [quickpod discord](https://discord.gg/CwgSdWVCHC). # Host Stores & Analytics Public host directory: Authenticated host routes: * `/my-store` * `/occupancy` * `/contracts` * `/earnings` ## Host stores QuickPod now includes a host storefront model, not just raw marketplace listings. Hosts can maintain a public-facing store profile with branding and a shareable store URL. Users can browse host-specific offers from the public host directory and then open a host's storefront directly. ## Public browsing flow 1. Open [Host Stores](https://console.quickpod.io/host-stores). 2. Choose a host storefront. 3. Browse the host's currently listed offers. 4. Launch from that storefront if the offer fits the workload. ## Occupancy analytics The occupancy route gives hosts a dedicated view into utilization and marketplace activity. This is part of the newer host experience and should be treated as a first-class host operations page. ## Contracts The contracts route helps hosts inspect contract and workload-related cost history tied to their listings. ## Earnings and payouts The host earnings surface is broader than the older docs suggest. Hosts now manage payout setup and review payout-related history through the current console experience. ## Why this matters for docs Older QuickPod docs described hosts mainly as machine listers. The current console also gives hosts public discovery, branding, analytics, and payout-management surfaces that deserve explicit documentation. # Contracts Authenticated route: `/contracts` ## What contracts show The Contracts page gives hosts visibility into workload and contract activity tied to their listed machines. ## Current capabilities The current host contracts surface includes: * GPU and CPU contract views * machine-level grouping * running hourly totals * storage-cost totals for non-running workloads * expand and collapse machine views * contract hardware summaries * cost totals per machine ## Why this matters Contracts are one of the main operational pages for hosts after their offers start receiving usage. They complement occupancy analytics and earnings history. ## Related docs * [Hosting Overview](/hosting/overview) * [Host Stores & Analytics](/hosting/host-stores-and-analytics) * [Earnings & Payouts](/hosting/earnings-and-payouts) # Earnings & Payouts Authenticated route: `/earnings` ## What this page covers The Earnings page is the host-side surface for payout setup and earnings visibility. ## Current capabilities The current console includes support for: * host earnings history * payout transaction history * Stripe connect and dashboard access * Stripe unlink and relink flows * PayPal payout email * Wise payout details * payout invoice download workflows ## Why this page matters Older docs often describe host payouts only at a policy level. The current product has a dedicated payout-management surface that hosts actively use inside the console. ## Related docs * [Hosting Overview](/hosting/overview) * [Host Stores & Analytics](/hosting/host-stores-and-analytics) * [Payouts & Taxes](/hosting/payouts-and-taxes) # Platform Fee QuickPod platform fee is flat 20% unless you are an early adopter who get a lifelong 10% platform fee. Early adoption is currently available for hosts with id < 1000. # Payouts & Taxes ### Payouts Payouts are made every Friday via paypal or stripe whichever method you have selected in your Host Settings. Invoices are also available in the Host Settings page. There is a minimum threshold of 5 usd. 20% or 10% platform fee will be deducted from earnings depending on your host status regular or early adopter. ### Guide to Taxes Disclaimer: As an independent contractor, you are responsible for keeping track of your earnings and accurately reporting them in tax filings. If you have any questions about what to report on your taxes, you should consult with a tax professional. QuickPod cannot provide you with tax advice nor can we verify the accuracy of any publicly available tax guidance online. Keep in mind: QuickPod does not automatically withhold taxes. We calculate the subtotal of your earnings based on the date the earnings were deposited. ### International Hosts QuickPod does not provide any tax documents or tax advice to hosts that reside and have their machines located outside the United States. ### United States If you earned $600 or more in tax year on the QuickPod platform as a host, We will send a 1099-MISC or 1099-K form to you either through our partner Stripe Connect, PayPal or another method. If you have a question or issue, email us at . # Hosting Agreement TERM & TERMINATION 1. This Agreement shall commence on the date user sets up a hosting account on quickpod.io. 2. The agreement may be terminated by either parties by ceasing to use the platform for hosting. Or disabling of the account by quickpod. USE OF HARDWARE The Hardware shall be located at the Provider and shall be used by quickpod for the purpose of renting out to quickpod users. Any use of the Hardware must be: (a) consistent with the use and function of the Hardware according to the manufacture’s design and instructions and consistent with the quickpod’s standards; (b) consistent with the terms of this Agreement; and (c) in accordance with all applicable government laws, rules and regulations. HARDWARE AS A SERVICE PAYMENTS Hardware will be rented out to quickpod customers for AI, ML and mining purposes, hosts will be paid out the accrued payments minus the platform fee which is 20% or 10% for early adopters. Payments shall be made by paypal or stripe, in case a valid payment method is not put on file payments will be held back until such information is provided. There is no fixed payout schedule when substantial payouts have accumulated we run the payout batches. OWNERSHIP OF HARDWARE The Hardware shall, at all times, be the property of Host. Quickpod shall have no rights or property interest therein, except for the right to use the Hardware in the normal operation of its business, during the term of this Agreement, consistent with the terms of this Agreement. OPERATION AND MAINTENANCE 1. Authorized Users shall use the Hardware and Software in a careful and proper manner, in accordance with all applicable manufacturer, developers and/or vendor specifications, solely in the conduct of its business, and will comply with and conform to all federal, state or local laws, ordinances and regulations relating to the use of the Hardware and Software. 2. Host shall provide Preventative Maintenance and Remedial Maintenance for the Hardware and Software during Regular Business Hours, as applicable, and shall furnish any and all parts or updates required to keep the Hardware and Software in good mechanical, operational and/or working order. 3. Host shall provide Preventative Maintenance and Remedial Maintenance when the Authorized User is not actively using the hardware. All host downtime may be recorded and displayed for Authorized Users to access the reliability of the hardware. 4. Uptime. Provider shall use best efforts to ensure that the Hardware will be available 24 hours per day, 7 days per week, excluding any scheduled downtime for maintenance. Reliability will be calculated based on this and displayed next to the machine listing. 5. Access. Host agrees to give QuickPod full access to the Hardware and Software. 6. Downloading, Storing, or Printing. Downloading, storing, reviewing, printing, or saving of the User’s data is strictly prohibited. 7. Data Breach Liability. If Host is subject to any claims relating to any data breaches or security incidents, Provider shall indemnify and hold harmless QuickPod and defend against any such claims, including reimbursement of any costs incurred by QuickPod relating to those claims. # Setup SSH Server on Pod Clone a public Template like Ubuntu 22.04 and modify the docker options to include -p 22:22 to expose port 22 to the internet. Connect to the pod using webssh //run the following commands `apt update` `apt install openssh-server vim` `cd /etc/ssh` `vi sshd_config` //uncomment the lines \#PermitRootLogin prohibit-password \#PasswordAuthentication yes save the file with Esc followed by :wq! //restart sshd with `service ssh restart` //go to /root/.ssh //and paste the contents of your public\_key in file authorized\_keys `chmod 600 authorized_keys` connect using default key file ssh -p EXPOSED\_PORT root\@POD\_PUBLIC\_IP replace EXPOSED\_PORT with the port mapping for 22 port and use the POD\_PUBLIC\_IP from connect popup
e.g. `ssh -p 42502 root@136.61.33.107` if your key is not in the default loation you can specify the key using -i e.g. `ssh -p 42502 root@136.61.33.107 -i key.pem` # API Documentation QuickPod exposes both public read-oriented APIs and authenticated update APIs. ## Swagger references * Read-only and public API: * Authenticated update API: ## API categories ### Public discovery APIs These routes back public console experiences such as: * [GPU Search](https://console.quickpod.io/) * [CPU Search](https://console.quickpod.io/cpu-pod-search) * [Templates](https://console.quickpod.io/templates) * [GPU Catalog](https://console.quickpod.io/gpu-types) * [Host Stores](https://console.quickpod.io/host-stores) Typical public API use cases include reading public templates, reading community templates, browsing rentable offers, reading GPU catalog data, and browsing host stores. ### Authenticated update APIs Authenticated routes cover user and host workflows such as: * pods * templates * clusters * cluster services * serverless endpoints * storage volumes and sync targets * account profile and billing * notifications * secure API keys * secrets ## Secure API keys QuickPod supports scoped secure API keys for automation. These are intended for integrations and scripts where you do not want to reuse an interactive session token. Examples of supported scope patterns in the product include read and write scopes for pods, machines, templates, storage, account data, contracts, and host store management. ## Serverless invoke paths QuickPod serverless endpoints are product-facing APIs built around invoke paths such as: * `/update/serverless/` These are configured from the authenticated serverless console and backed by cluster services. ## Guidance Use the public API for discovery and browsing. Use the authenticated update API for actions that create, modify, or destroy user resources. # CLI QuickPod now has a Go-based CLI that covers the current user-facing QuickPod platform surface. Repository: * ## What the current CLI covers The current CLI supports workflows for: * search * pods * templates * clusters * serverless endpoints * storage volumes * machines * account and auth * catalog data * host stores * security and 2FA ## Install Latest installer: ```bash curl -fsSL https://raw.githubusercontent.com/quickpod/quickpod-cli/main/install.sh | sh ``` ## Build from source ```bash git clone https://github.com/quickpod/quickpod-cli.git cd quickpod-cli go build -o quickpod ``` ## Authentication The CLI supports bearer-token and secure-API-key based use. Examples: ```bash quickpod auth login --email you@example.com quickpod auth me quickpod --api-key "$QUICKPOD_API_KEY" pods list --kind gpu ``` ## Common commands Search offers: ```bash quickpod search gpu --type A100 --max-hourly 2.5 quickpod search cpu --max-hourly 0.25 --min-count 8 ``` Work with pods: ```bash quickpod pods list --kind gpu quickpod pods get --kind gpu --pod POD_UUID quickpod pods create --kind gpu --template TEMPLATE_UUID --offer OFFER_ID --disk 50 --name trainer quickpod pods stop --kind gpu --pod POD_UUID ``` Work with templates: ```bash quickpod templates list --scope public --kind gpu quickpod templates list --scope community --kind cpu ``` Work with clusters and serverless: ```bash quickpod clusters list quickpod serverless list ``` ## Related docs * [API Documentation](/api-and-cli/api-documentation) * [Serverless](/console/serverless) * [Clusters](/console/clusters)