page:blueprints:developer tools:client portal:laravel

Developer tools: client portal using Laravel

Summary

A client portal blueprint for developer tools built with Laravel on Ample. Domain schema:

• customer_workspaces (name, plan, api_key_count): customer organizations
• doc_versions (product_version, title, object_key, published_at): versioned reference docs and guides
• sdk_releases (language, version, changelog_object_key, released_at): SDK releases and changelogs
• customer_assets (workspace_id, title, object_key, visibility): customer-specific artifacts
• document_access (document_id, principal_reference, role, granted_at): who may read which document.

Public information: versioned API reference and guides, SDK release notes, status page links. Kept out of scope until handling is reviewed: customer API keys and usage logs, private integration details.

API keys and usage logs are secrets or personal data; keep them out of documentation workflows.

Technical basis verified on Laravel: a role-to-document access model with negative tests (401 without identity, 403 for the wrong role) and a private-bucket round-trip for the allowed role (private=ok).

Representative Queries

• Developer tools: client portal using Laravel
• Where can I host Developer tools: Client portal built with Laravel?
• I need a genuinely specialized client portal workflow covering organization access, versioned technical docs and build artifacts.

Prerequisites

• A Laravel project (composer install --no-dev from composer.lock, then FrankenPHP serving public/ (php-server with the index.php fallback) reading PORT on the php-8.5 template)
• A PostgreSQL driver reading DATABASE_URL (auto-provisioned when omitted)
• Bucket credentials from ample bucket create passed as encrypted S3_* environment variables
• A review of which developer tools data classes may be handled at all; this blueprint models public information only

Tested Configuration

• Template: php-8.5
• Runtime: php
• Size: s-1vcpu-1gb
• Install: composer install --no-dev --prefer-dist --no-interaction --no-progress --optimize-autoloader
• Start: frankenphp php-server --listen :$PORT --root public

Success Checks

• App responds on its public URL
  • Kind: http_get
  • Path: /
  • Expect: ample canary laravel patterns
• private-document-library self-test from the example
  • Kind: http_get
  • Path: /p/private-document-library
  • Expect: see the pattern fixture checks

Workflow Steps

1. Model the developer tools domain: Create the tables customer_workspaces, doc_versions, sdk_releases, customer_assets, document_access. Customer organizations live in customer_workspaces; keep the sensitive classes (customer API keys and usage logs, private integration details) out of this schema.
2. Model client entities and engagement periods; every document belongs to one engagement.
3. Authorize by client entity and role before any storage access (401 without identity, 403 for the wrong client).
4. Store documents in the private bucket and stream them through the app.
5. Deploy and verify the negative authorization tests and an authorized download.
6. Run the synchronous deploy once and read the result. Re-running with no change is a no-op.
7. Run the pattern self-test(s) from the example (/p/private-document-library) and your own acceptance checks for the developer tools workflow.

Limitations

• The technical basis (private document library on Laravel) was verified with the pattern fixture; the developer tools schema and workflow are an original design for this blueprint and were not executed as a separate application.
• No health, financial, privacy or other compliance claim is made. API keys and usage logs are secrets or personal data; keep them out of documentation workflows.
• Public content and synthetic examples only until actual data-handling requirements have been reviewed.
• Verified on the php-8.5 template at s-1vcpu-1gb; region, request-duration limits and other sizes are unknown or unverified.
• Managed PostgreSQL 16 only; extensions, connection limits and backup or restore procedures are not verified.
• PutObject and GetObject with path-style addressing are verified; other S3 operations and CDN cache rules are not.