Skip to content

group(enhancements): Albacore #158

Description

@nfebe

Albacore release. Theme: full deployment lifecycle and self-healing operations.
Umbrella for the next release; each item below ships this cycle.

Features

  • Observability & self-recovery (feat: Add AI-native observability and self-recovery module #148): shipped in feat(observ): Add observability engine, plugin tool bridge, notifications #165 and feat(observ): Add observability UI, plugin slots, notifications settings ui#78. OTel-semconv metrics with a native time-series UI, health self-heal scoped to FlatRun-managed deployments only (capped retries with cooldown, so an external container can't trigger a restart loop), a core notification system wite email/webhook targets and test-send, and a plugin framework that lets a plugin inject UI sections, contribute settings, and expose tools the AI assistant can call. Follow-ups tracked under Improvements; none blocked the release.
  • S3-compatible backups (feat(backup): Add remote S3-compatible backup destinations #168, ui: Object stores, a base component library, and dark-mode fixes ui#79): backups now mirror to remote S3-compatible object storage (AWS, R2, B2, MinIO) on top of the always-local copy, best-effort so a remote outage never fails a backup. What/how/where is documented in docs/BACKUPS.md; object-storage secrets live in the credential manager, never the flat-file config. This also seeds the object store abstraction (external vs managed stores, a MinIO template so FlatRun can run its own S3 endpoint), specced in docs/OBJECT_STORES.md. Follow-up slices, still open: one-click managed deploy with auto-register, an object browser, deployment consumption, and store-to-store replication.
  • Dashboard & API performance (performance: Loading deployments and the dashboard is generally too slow #154): progressive / lazy loading for the deployments
    list and dashboard instead of loading everything at once; profile and optimize the
    backend paths behind those views. This item is about how fast FlatRun's own UI and API
    respond, not how fast the deployed apps serve their traffic (tracked separately below).
    Backend profiling (this cycle): deployment status is recomputed on every request by
    shelling out to the docker compose CLI with nothing cached, so latency scales with
    the number of deployments and is dominated by process startup. Listing N deployments
    spawns 2N to 4N docker processes; a single detail view spawns 4 to 8. Concrete work:
    • Memoize compose-command detection so docker compose version runs once per process,
      not once per runCompose (internal/docker/compose.go:369, :469).
    • Serve list/detail status from one Engine API ContainerList filtered by
      com.docker.compose.project labels, reusing the existing APIClient
      (internal/docker/api.go:17, :33), instead of per-deployment docker compose ps.
    • Collapse the detail path that runs the compose sequence twice into one status read
      (internal/docker/manager.go:101, :104).
    • Skip the status fan-out for endpoints that only need on-disk metadata (certificates,
      proxy sync, traffic, cluster), reading via FindDeployments rather than
      ListDeployments (internal/api/server.go:4598, :5000).
    • Add a short-TTL cache for container status so request bursts don't each recompute it.
    • Record before/after list and detail timings at 1, 10, and 50 deployments.
  • Deployment serving performance: how fast a deployed app answers real end-user
    requests through FlatRun's reverse proxy, distinct from dashboard/API speed above. The
    proxy is the shared path every deployment's traffic crosses, so its defaults set the
    floor for everyone. Establish a baseline and remove the obvious drags:
    • Measure request latency and throughput through the proxy to a deployment (p50/p95,
      requests/sec) against hitting the container directly, so proxy overhead is a number.
    • Audit the generated nginx/openresty vhost defaults: keepalive to upstreams, gzip,
      HTTP/2, sensible proxy buffer sizes, and static-asset caching headers.
    • Confirm no per-request work scales badly (excess logging, TLS session cache off,
      DNS re-resolution of upstreams).
    • Surface per-deployment request latency in the observability UI so a slow app is
      visible next to its CPU and memory, closing the loop with feat: Add AI-native observability and self-recovery module #148.
    • Document knobs an operator can turn per deployment (worker limits, cache toggles).
  • Integrations: deploy from a GitHub or git URL and from uploaded code, not only
    from compose content or a template. Today a deployment must already have a compose
    file; this adds source-based deployment with auth.
  • Builders: build code and then deploy it. Today only an existing compose build:
    section runs. This adds build-from-source (Dockerfile detection, buildpacks / nixpacks)
    with build config (args, cache, secrets).
  • More AI tools (feat(ai): Add more tools for quick actions, file editing, summarization etc #147): expand the AI assistant with quick actions, file editing,
    summarization, and related tools (UI side: feat(ai): Add AI workflow to file viewers/editors accross the application ui#71).
  • Persist AI chat sessions: store conversation history so chats survive reloads and
    can be resumed, instead of being lost per session.
  • Marketplace-sourced templates: the deployment flow's templates should come from the
    marketplace (api.flatrun.dev) and be kept current, with flatrun/marketplace on GitHub
    as the fallback source for public publications when the API is unreachable. Today the
    deploy flow uses the templates embedded in the agent binary.
  • Firewall enforcement: the built-in firewall app persists, validates, and previews a
    host-wide inbound/outbound policy, but does not enforce it yet. Translate rules to
    nftables/iptables with a safeguard that preserves the active SSH session before a
    default-deny inbound policy takes effect.

Improvements

Housekeeping

  • Document the release naming system: keep the convention below current and reuse
    it when opening the next umbrella issue.

Release naming: umbrella releases are codenamed after sea creatures, advancing one
letter per release. Albacore (A) -> Barnacle (B) -> Cuttlefish (C) -> Dolphin (D) ...
Pick the next unused letter when opening each new group(enhancements): issue.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions