VibePackr
Website menu
DOCUMENTATION / R17
Review draft

Customer & PoC Getting Started

Plan a small evaluation of VibePackr, identify the people and inputs you need, and understand the checkpoints between a deployed VM and a first work result.

English website review edition · Appliance reference: 0.1.0-r232

Website review draft · Documentation R17 · Customer procedure validation pending

01 · Start here: your first useful result

VibePackr governs what AI can execute. It runs as a dedicated virtual machine (VM) in your organization’s Google Cloud project. A VM is the cloud computer that hosts the product; it is operated through supported commands and services by default, rather than assuming a public administration website.

For a proof of concept (PoC)—a small evaluation with an agreed goal—choose one permitted work item and define how you will judge its result and cost. Your team prepares the project, responsible people and non-secret sample input. The supplier must provide the matching delivery package and supported setup instructions. The product checks its own state and, once the necessary access and connections are established, the work can be evaluated through the supported procedure.

Your first useful result today is a clear PoC plan: the work you want to evaluate, who owns each setup step, and which supplier instructions are still needed. The later operational milestone is one permitted work result reviewed against that plan; this draft does not yet provide a complete route to that milestone.

Readiness at a glance. The product baseline is 0.1.0-r232. The supported first-product-administrator procedure is unavailable in that baseline; policy approval, implementation and customer validation are pending. The final delivery package/version, customer AI and storage setup, and full first-use/lifecycle checks also remain open. You can prepare now; administrator-dependent execution waits for the supported procedure.

First reading: find your role → see a small PoC example → prepare your evaluation → check the first-administrator dependency. Use the later steps when the matching delivery instructions are available. Common questions and the glossary are at the end.

02 · People, access and the parts you will configure

The PoC owner decides what a useful result is. The cloud administrator manages the Google Cloud resources. An authorized maintenance operator connects to the VM. The product administrator uses the customer-administration functions permitted by VibePackr. One person may do several jobs, but each job needs its own access.

A concrete example: a cloud administrator may be allowed by Cloud IAM (Google Cloud’s access-control system) to create a VM. SSH gives an authorized operator a terminal session on that VM, for example to run the supplied health check. Neither action creates the first VibePackr product administrator. That separate access must come from the supported product procedure, which is still pending.

PartWhat it contributesWhat to prepare
VM and networkA place for the appliance to run and the connections it usesCloud owner, project, location and network choices; confirm the final package’s permissions and resources
Product administrationAccess to permitted functions inside VibePackrA named organizational contact and a request for the supported first-admin procedure
Vertex AIGoogle Cloud’s AI service, used for the selected AI model when configured through the supported integrationAI owner, intended model/location, service identity and cost/access review; installation alone does not configure it
StorageThe boot disk hosts the system; separate durable state storage and object storage have different retention rolesData owner and retention/cost decisions for each resource; exact customer connection and deletion instructions are pending

If your PoC includes an external integration, the Developer Guide explains the Integration Helper, SDK and Contract/Document roles. Cloud access is preparation for that work, not evidence that the integration is ready.

03 · A small PoC, from intention to review

Illustrative planning scenario—not an executable product example. Your team wants to assess one supplier-supported AI work item using a short, non-confidential sample. First agree on the permitted task and what a useful result would look like; a candidate task still needs the supplier’s supported input and submission route.

The PoC owner brings the goal, sample and acceptance criteria. The cloud/AI owner brings the project, intended location/model and cost limit. The data owner decides what may be retained. The supplier must supply the matching deployment and first-admin instructions, followed by the customer AI/storage procedure and a first-work example.

The journey is prepare → deploy and check base health → establish product access and required connections → run one permitted item → review its state, result and cost. At the health checkpoint you learn whether the base appliance check passed. At the final checkpoint you would inspect the returned work state and result against your goal; a specific payload or output is not promised here. Today the first-admin dependency prevents completing this journey, so record that dependency and request the missing procedure through support.

For the integration part of this PoC, use the same status.read document example. For assistant-led review, choose an agent recipe. These local document exercises do not require or complete a customer VM deployment.

04 · Before you begin: owners, costs and PoC scope

Planning

A small, agreed scope makes the PoC result useful: everyone knows which work is permitted, who pays for it and what would count as success.

Who
Customer PoC owner and cloud administrator
Prepare
Prepare a Google Cloud project with billing, organizational deployment approval, named contacts and representative work input without secrets.
Sequence
  1. Review the software offer and terms separately from infrastructure and AI-service charges.
  2. Agree with the supplier on the PoC goal, permitted work, expected result, cost limit and stopping conditions.
  3. Identify the project, zone, VPC/subnet and owner of data-retention/deletion decisions.
Success check
The owners, approved scope, costs and acceptance criteria are documented.
Stop and report
If authority or cost ownership is unclear, stop before deployment and send the missing decision to the responsible owner.

05 · Enter Marketplace

Final package/procedure pending

The listing ties the software offer to a specific delivery package. Checking it before deployment prevents the team from following instructions for a different version.

Who
Customer deployment contact; supplier provides the exact listing
Prepare
A supplier-confirmed listing URL, delivery version, offer, terms and support conditions. The final URL and delivery package are pending.
Sequence
  1. Request the listing and exact deployment version from the supplier.
  2. Review its product name, version, costs, support, terms and Getting Started link.
  3. Continue to deployment only when these match the agreed offer.
Success check
The target listing, delivery version and working documentation links are confirmed. Customer confirmation of these conditions is pending.
Stop and report
If the listing or version is missing or differs, send the URL, displayed version and mismatch to the supplier; do not start installation.

06 · Deploy the VM

Final package/procedure pending

Deployment creates the cloud resources that host the appliance. Review what will be created and paid for before starting; a VM’s running state only tells you that the cloud computer is on.

Who
Authorized customer cloud deployment contact
Prepare
The target project, zone, network/subnet, service identity and final deployment package. Confirm permissions, ports and created resources in that package.
Sequence
  1. Use the reference sizing below to agree on VM and storage choices for the intended workload.
  2. Review created resources and default port behavior. Do not assume a public administration website or an HTTP/HTTPS listener on ports 80/443.
  3. Follow the approved deployment sequence in the final package and retain its completion indicator and resource list. The complete executable sequence is pending.
Success check
The VM for the exact delivery version and agreed resources exist, and the package reports completion. A running VM alone is not application readiness.
Stop and report
Record the failed resource, deployment error and selected region/zone and sizing. The cloud owner and supplier should resolve the cause before changes or redeployment.

Reference sizing: e2-standard-2 · 2 vCPU · 8 GiB · Debian 13 x86_64 · 20 GiB boot disk. A separate 50 GiB durable disk and 100 GiB live Cloud Storage data are planning figures, not minimum requirements, performance guarantees or provisioned resources. Support across all regions is not established.

07 · Establish access

Bounded retained evidence

A maintenance session lets the authorized operator check the VM and run the supplied diagnostics. Keep this access separate from the product-administration access needed later. IAP is Google Cloud Identity-Aware Proxy, used for the retained SSH access path.

Who
Authorized SSH maintenance operator
Prepare
Connection instructions from the final package and customer IAM/network configuration. A retained bounded deployment used IAP SSH without an external IP.
Sequence
  1. Confirm the supported access method and target VM.
  2. Follow the SSH instructions supplied for the customer environment.
  3. Confirm the target VM and delivery version after connecting. SSH access is separate from product administrator privileges.
Success check
The authorized operator connects to the maintenance session on the correct VM. This does not establish a product administrator login.
Stop and report
If connection fails, send the error, target zone and access method to the customer cloud administrator. Do not bypass it by widening firewall rules or privileges.

08 · Initialize and check base health

Bounded retained evidence

First boot sets up the appliance automatically. The health command below is the first checkpoint for its base state, helping you report a setup problem before attempting product use.

Who
Authorized SSH maintenance operator
Prepare
A correctly deployed appliance and maintenance session. First-boot initialization runs automatically and is separate from first-administrator issuance.
Sequence
  1. After first-boot initialization, run the existing read-only health command below.
  2. Check its exit code and returned state; retain unavailable or unevaluated fields as reported.
  3. If the check succeeds, continue to the first-administrator step. Do not edit product state files.
Success check
Exit code 0 means that the base health check passed. customer_binding_state=BOUND identifies a customer association; customer_operation_authority=NOT_EVALUATED means permission for customer operations has not been checked by that result. Keep both values as reported. Administrator access, AI and overall readiness still need their own checks.
Stop and report
On failure, send the version, failed step and sanitized error to support. Do not use repeated restarts to force a successful check.
Initialize and check base health
sudo /opt/vibepackr/health

09 · Request the first product administrator

Approval / implementation / validation pending

The first product administrator is the starting point for permitted customer administration inside VibePackr. A cloud account or SSH session cannot supply this product access. You can request the missing instructions now without sending credentials.

Who
Customer contact and supplier
Prepare
The product version, organizational contact and installation stage. A supported issuance procedure is not yet available.
Sequence
  1. Contact support with the subject “First product administrator procedure” and the product version, your organizational contact and the installation stage reached. Ask for issuance, delivery, initial-access and interrupted-setup recovery instructions for that version.
  2. If installation identifiers are needed, wait for support to specify the minimum fields and private channel. Do not attach credentials or full logs.
  3. Continue planning AI, storage and the PoC while the procedure is pending. Apply administrator-dependent configuration only after supported product access is established.
Success check
The future supported procedure must provide access to the permitted customer-administration functions. Policy approval, implementation and customer validation are pending.
Stop and report
The r232 new-customer path stops here. Cloud IAM, OS root, SSH access or purchase do not substitute for issuance authority. Issuance timing and SLA are not established.

10 · Prepare Vertex AI configuration

Customer procedure/validation pending

An AI work item needs the intended model to be reachable under the correct cloud identity and billing conditions. The service identity is the account the software uses to access Google Cloud; agree on these choices before configuring it.

Who
Customer cloud/AI owner and supplier
Prepare
Project, location, model, billing/API/model-access policy, service identity and network reachability. Administrator-dependent configuration requires the previous step to be resolved.
Sequence
  1. Confirm the supported model/location and input method for the delivery version with the supplier.
  2. Have the cloud owner review the actual identity, minimum permissions/access scopes, credential renewal/revocation and network requirements.
  3. Apply configuration only after a validated customer procedure is supplied, then use a permitted small AI work item to confirm the selected model/runtime and result. Executable setup commands are pending.
Success check
An authorized AI work item and result must be verified on the exact customer VM/identity/model combination. Vertex AI integration exists, but it is not automatically configured on installation.
Stop and report
Provide the project/location/model context and sanitized error. Do not place service-account keys in VM metadata or silently substitute another provider.

Continue with the AI setup worksheet and step-by-step Vertex explanation, including request shape, identity differences and failure checks. GAPE structure observation itself does not call Vertex AI.

11 · Configure storage and retention

Customer procedure/validation pending

VMs, disks and stored objects can have different lifetimes. Decide which data should remain when compute stops or is replaced, then confirm how the delivered product actually uses each storage resource.

Who
Customer data/cloud owner and supplier
Prepare
Owners, locations, retention/deletion and cost decisions for the boot disk, separate durable disk and object storage. Planning capacities are not a list of provisioned resources.
Sequence
  1. Request the mapping from deployment inputs to storage actually consumed by the product.
  2. Confirm new-disk initialization, existing-disk attachment and per-resource retention on VM deletion.
  3. After the customer path is connected through a validated procedure, verify the required read/write and retention results. Final setup and deletion procedures are pending.
Success check
Selected storage must match the actual consumer path, with approved retention behavior verified. Retained disk/object tests do not prove complete customer recovery.
Stop and report
Report each resource state and the intended retention outcome; stop further initialization or deletion.

12 · Verify readiness

Overall readiness unproven

Readiness brings the separate checks together. Product entitlement means permission to use the product under the agreed offer; a Marketplace VM license is a different check. Both access and the connections required for your chosen work must be established.

Who
Customer product/PoC owner and supplier
Prepare
Individual installation, administrator, entitlement, AI and storage results. The Marketplace VM license and product entitlement are separate.
Sequence
  1. Confirm base health, supported administrator access and product entitlement for the approved offer.
  2. Confirm the required customer AI/storage connections and observed behavior.
  3. If any required item remains incomplete, record its owner and next action without marking overall READY.
Success check
Every required item is confirmed for the customer delivery version. Overall new-customer readiness is currently unproven.
Stop and report
Stop at incomplete items and report results, version and unresolved conditions. A running VM or successful health check is not a substitute.

13 · Run the first work item and review the PoC

Customer procedure/validation pending

One small work item connects the setup to your PoC goal. Agree on the input and how to inspect the result before running it, so a completed operation can be judged against a useful outcome.

Who
Authorized customer operator and PoC owner
Prepare
Completed required readiness items, a supported submission route, a permitted small input and expected result. The reproducible customer submission sequence is pending.
Sequence
  1. Read the Headless work reference or PackrGUI guide. Confirm the delivery version, permitted operation and input with the supplied package before submission.
  2. Run within the agreed scope only after prerequisites are confirmed.
  3. Review state, actual runtime, result, errors and cost, then record acceptance against the PoC criteria.
Success check
The expected result and data/cost boundaries are met and reviewed by the owner. One retained local work item and one authorization denial do not validate all customer or AI work.
Stop and report
Retain the failed step, work reference and sanitized error. Do not introduce unauthorized retries, privilege expansion or provider changes.

14 · Stop and restart

Customer procedure/validation pending

Stopping a VM, restarting a product service and resuming interrupted work are different actions. The right procedure depends on which state you intend to change and what must be retained.

Who
Authorized customer operator and cloud owner
Prepare
Handling of in-flight work, resumption behavior, retained resources and ongoing costs. VM stop/start and product-service restart are separate.
Sequence
  1. Identify whether the action concerns VM lifecycle or product-service control.
  2. Use the documented VibePackr Admin service procedure only with established product access, the supported request inputs and authorization. Command syntax exists; completion of the new-customer setup remains pending.
  3. After starting, recheck base health and required individual readiness items.
Success check
The intended transition and required readiness are confirmed. This does not guarantee uninterrupted operation, zero loss or automatic work resumption.
Stop and report
If the state differs from the intended result, stop further restarts and report before/after states and errors.

15 · Retire usage and delete resources

Customer procedure/validation pending

Ending a PoC should leave resources and data in the state your organization intended. Deleting the VM may leave disks, objects or ongoing charges, so review each resource before taking a permanent action.

Who
Customer data owner and cloud administrator, with supplier support
Prepare
An exact resource inventory, retention/deletion decisions for each resource, required records and approval. The final customer deletion procedure is pending validation.
Sequence
  1. Separate product retirement, VM deletion and permanent data deletion into distinct decisions.
  2. Confirm deletion effects and remaining costs for boot/durable disks, objects, backups and related resources.
  3. Act only with a validated procedure and exact authorization, then verify completion for each resource. This draft provides no deletion command.
Success check
The actual resource state matches the retention/deletion decision and is confirmed by the customer. Test-resource cleanup does not prove complete deletion of customer data.
Stop and report
If any resource is unclear or unexpected, stop further deletion and report the inventory and state.

16 · A few terms used in this guide

PoC
A small evaluation with agreed work, costs and success criteria.
Headless appliance
A product operated through supported commands and services by default; do not assume a public web console.
Base health
A limited check of the appliance’s base state. First-use readiness also requires product access and the connections needed for the chosen work.
Entitlement
The product-use permission associated with the agreed offer, checked separately from a VM license.
Durable storage
Storage intended to retain state beyond replaceable compute; the actual attachment and retention procedure must match the delivery package.
Contract / Document
A Contract describes a supported integration interface. A Document describes the integration you want checked against it; it does not grant permission to run it. See the developer explanation.

17 · Common first-use questions

I can SSH into the VM. Can I administer VibePackr?

You have a maintenance session. Product administration needs separate product access; see the first-administrator step.

The health command succeeded. Can I start the PoC?

That establishes the base-health checkpoint. Check administrator access, entitlement and required AI/storage connections before submitting work.

What can I do while the setup procedure is pending?

Agree on the goal, permitted sample, contacts, cost limit and retention needs. Ask support for the exact delivery version and the specific missing procedure. This gives your team a usable preparation plan without guessing commands.

Does stopping the VM stop all charges or delete my data?

Other resources may remain and continue to incur charges. Use the resource inventory and per-resource retention/deletion decisions; the final customer lifecycle procedure is still pending.

18 · Contact support

Support: support@vibepackr.com · VibePackr website

Name the missing procedure or failed stage in the subject, such as “First product administrator procedure” or “Base health check failed.” Include the product version, stage reached, expected result, observed result and a short sanitized error. If you have not installed yet, say that the version is unknown and request the exact delivery version/package.

Send SSH/cloud-access issues first to your cloud administrator; send product setup, procedure or health-check issues to VibePackr support. If ownership is unclear, use the same short description to identify the responsible contact. Do not send passwords, tokens, private keys, full logs or customer work content. Provide extra identifiers only after support specifies the minimum fields and private channel. Automatic log collection and response times are not guaranteed here.

For integration development, see the Developer Guide; for Google review navigation, see the Reviewer Guide.

19 · Continue with the operating guides

Use Headless for terminal operation, PackrGUI for desktop work, VibePackr Admin for appliance management and Packtory Admin for its separate management surface. Start with Troubleshooting when the observed state differs from the procedure.