Scaleway Containers adds initial support for a Waypoint plugin: what it means for serverless container deployments

AI generated image for Scaleway Containers adds initial support for a Waypoint plugin: what it means for serverless container deployments

Scaleway quietly slipped a very developer-friendly note into its documentation changelog: Containers now have initial support for a Waypoint plugin. If you’ve ever wished your deployment workflow had fewer bespoke scripts, fewer “just run this one-off CLI command” README steps, and fewer opportunities to paste the wrong namespace ID at 2 a.m., this is the kind of “small” update that can make an outsized difference.

The original changelog item lives here: Scaleway Documentation – Changelog: Initial support for Waypoint plugin. The changelog page itself doesn’t expose much detail in a static view, but Scaleway has published a companion tutorial that lays out what “initial support” actually looks like in practice: a Waypoint plugin that targets Scaleway’s Serverless Containers product. Configuring Scaleway plugins for Waypoint (reviewed July 21, 2025) walks through installation and usage. citeturn6search0

Let’s unpack what’s been released, why it matters (even if you don’t currently use Waypoint), where it fits into the modern platform engineering mess… and what you should watch out for when you try to productionize something that’s explicitly labeled “initial.”

What exactly launched: a Waypoint “platform” plugin for Scaleway Serverless Containers

Waypoint (from HashiCorp) is a deployment tool designed to standardize application delivery across targets. It uses plugins to support different build, deploy, and release systems, with the famous developer-facing workflow distilled into a single command: waypoint up. HashiCorp has described Waypoint as fully extensible via plugins, using a plugin system similar to Terraform’s approach. citeturn0search1

Scaleway’s documentation indicates it currently provides one Waypoint plugin, named container, which adds support for deploying to Scaleway. citeturn6search0

In Waypoint configuration terms, the Scaleway plugin is used in the deploy stanza, like this (from Scaleway’s tutorial):

deploy {
use "scaleway-container" {
port = 80
namespace_id = "<YOUR_SCALEWAY_NAMESPACE_ID>"
region = "fr-par"
}
}

This strongly suggests that the initial release focuses on the “deploy” part of the Waypoint lifecycle, wiring Waypoint into Scaleway’s serverless containers API surface (namespaces, container definitions, deployments, etc.). citeturn6search0turn1search1

Practically, this means that teams already using Waypoint can treat Scaleway Serverless Containers as another deployment target—similar in spirit to how Waypoint supports Kubernetes, ECS, and other platforms via plugins. citeturn0search5

Why this matters: deployment tooling is still painfully fragmented

In 2026, we’ve collectively standardized on containers… and then immediately reinvented fifty ways to ship them. Your organization likely uses some combination of:

  • GitHub Actions (or GitLab CI, CircleCI, etc.)
  • Terraform/OpenTofu to provision infra
  • Kubernetes manifests or Helm charts
  • A registry (GHCR, ECR, Scaleway Container Registry, etc.)
  • Some “temporary” Bash scripts that became permanent in Q2 of “last year” (which year? doesn’t matter; it’s eternal now)

Waypoint’s pitch is that the workflow should be consistent: define a waypoint.hcl file, then let plugins handle target-specific details. Scaleway integrating via a plugin is significant because it makes Scaleway Serverless Containers feel like a first-class “platform” in that ecosystem, rather than a special case requiring custom pipeline work.

The key value: a consistent dev workflow with fewer vendor-specific steps

If you already run Waypoint, adding Scaleway as a deployment target can reduce the need to teach every team the “Scaleway Containers way” of doing things. It becomes “the Waypoint way,” with Scaleway as an implementation detail.

If you don’t run Waypoint, the launch still matters: it’s another indicator that Scaleway wants to be part of mainstream developer tooling flows (alongside its Terraform provider, CLI, Serverless Framework plugin, and APIs). The Serverless Containers API is explicitly designed for event-triggered container workloads with autoscaling and scaling to zero. citeturn1search1

Quick refresher: Scaleway Serverless Containers, and why “serverless containers” are having a moment

Scaleway Serverless Containers is a Container as a Service product where you deploy a container image and let the platform handle scaling and execution. According to Scaleway’s API documentation, the product is built around the idea that containers can be invoked by triggers (HTTP, CRON) and can scale to zero when idle, which can reduce costs for spiky or low-traffic workloads. citeturn1search1

From the API reference, some of the key platform characteristics include:

  • Scaling to zero when the container isn’t executing
  • Configurable min/max replicas and autoscaling
  • Trigger types like HTTP and CRON
  • Integration with Scaleway Container Registry
  • Availability across regions including fr-par, nl-ams, and pl-waw

All of that matters for Waypoint because Waypoint is primarily about abstracting away “where” and “how” you deploy. A platform that already wraps orchestration for you is a natural fit for a deployment orchestrator. citeturn1search1

So where does Waypoint fit vs. Kubernetes?

Kubernetes is great if you want control, portability, and a broad ecosystem. It’s also great if you enjoy becoming an amateur distributed systems engineer on weekends.

Serverless containers sit in the “I want to ship a container without owning a cluster” middle ground. They compete (conceptually) with services like Google Cloud Run, AWS App Runner, Azure Container Apps, and similar offerings. Waypoint historically positioned itself as a unifying layer across such targets, with plugins enabling consistent delivery. citeturn0search5

Scaleway’s plugin is a signal: Scaleway wants to be in that shortlist of “simple container platforms” that teams can pick without needing a whole new deployment pipeline.

What “initial support” likely means: good enough to ship, not yet a full platform story

Changelog language matters. “Initial support” usually translates to: this is the first cut, expect gaps. Based on Scaleway’s own tutorial, the plugin exists and is usable, but it is currently described as the only available plugin and it is specifically the container plugin. citeturn6search0

Waypoint, however, is a broader system with plugin types across the lifecycle—builders, deployment platforms, registries, release managers, etc. HashiCorp’s deep-dive materials emphasize these plugin categories and how they work together. citeturn0search5

So you should assume the Scaleway integration is focused primarily on deployment to Serverless Containers, and you may still need separate tooling for:

  • Building container images (Docker or buildpacks)
  • Pushing images to a registry (Scaleway Container Registry or elsewhere)
  • Releasing traffic switching/rollbacks (where applicable)
  • Advanced observability beyond whatever the platform provides by default

That’s not a criticism—this is how most “v1” integrations ship. The important part is that the deployment surface exists and is documented.

How the plugin works operationally (conceptual view)

Scaleway’s tutorial gives a practical install-and-run path (including a demo repo and a setup script), but let’s translate the workflow into a model you can reason about as a platform team:

1) Credentials and configuration: Waypoint consumes Scaleway API keys

Scaleway notes that API keys are loaded from Scaleway’s config default profile and can be overridden by environment variables. citeturn6search0

In other words, your local developer machine (or CI runner) needs access to Scaleway credentials in some standardized format. This aligns with how many teams already use the Scaleway CLI and its config handling. citeturn0search3

2) Target selection: namespace and region

The example config requires namespace_id and region. A Scaleway “namespace” in Serverless Containers is effectively a grouping boundary for containers with shared configuration possibilities. citeturn1search1

This choice will affect:

  • where your container runs (latency, data residency considerations)
  • which registry endpoints you’ll use
  • how you scope access control (who can deploy into which namespace)

3) Deployment: using the Serverless Containers API model

Under the hood, the plugin almost certainly maps Waypoint’s “deploy” concept to API operations like “create/update container” and “deploy container” in Scaleway’s Serverless Containers API. The API includes endpoints to create containers and explicitly trigger deployments. citeturn1search1

The details matter because “serverless containers” are not Kubernetes deployments. You may not get features like canary traffic shifting out of the box unless the platform (or plugin) implements it.

Step-by-step: what a developer experience could look like (without pretending it’s magic)

Based on Scaleway’s tutorial, a plausible developer flow would be:

  • Install Waypoint
  • Install the Scaleway Waypoint plugin (download a release ZIP or build from source) citeturn6search0
  • Authenticate to Scaleway (often via CLI config or environment variables) citeturn6search0turn0search3
  • Configure waypoint.hcl with the scaleway-container deploy stanza citeturn6search0
  • Run waypoint init and then waypoint up to deploy citeturn6search0

This is clean—and for many teams, that alone is worth the price of admission (which, in open source tooling terms, is usually “your time and attention span”).

Where the real work still is: CI/CD, image lifecycle, and policy

Waypoint is not a replacement for everything. It’s a workflow layer. You’ll still need to decide how your images are built, scanned, and promoted across environments.

One practical comparison: many teams deploy to Scaleway Serverless Containers today using CI automation such as GitHub Actions. There’s even a community GitHub Marketplace action focused on deploying containers to Scaleway Serverless Containers. citeturn1search2

A Waypoint plugin can be a more standardized interface for developer workflows, but GitHub Actions (or equivalent CI) is still the place where you might enforce controls like:

  • SBOM generation
  • container vulnerability scanning
  • signature verification / provenance checks
  • policy gates for production promotion

Industry context: Waypoint’s evolving story and why plugins still matter

Waypoint started as an open-source HashiCorp tool aimed at simplifying deployments with a consistent interface and plugin-driven extensibility. HashiCorp’s original announcement emphasized that the system would be “fully extensible via plugins,” explicitly drawing parallels to Terraform’s provider ecosystem. citeturn0search1

Over time, HashiCorp also pushed managed offerings in its cloud platform (HCP), and Waypoint has had a shifting narrative in the market—something the community has discussed. More recently, HashiCorp continues to ship features around HCP Waypoint capabilities such as integrating Waypoint actions into GitHub Actions workflows (in private beta as of November 3, 2025). citeturn5search4

Why mention this in a Scaleway article? Because Scaleway’s plugin investment is a bet that Waypoint—whether open source or managed—remains a meaningful integration point for teams. Even if your organization doesn’t standardize on Waypoint long-term, the plugin approach is still strategically useful: it externalizes deployment integration into a stable, testable component.

Plugin ecosystems are “boring” in the best way

HashiCorp publishes a Waypoint Plugin SDK that describes how plugins are separate binaries that communicate with Waypoint via gRPC, and recommends using the official SDK (Go) to build them. citeturn5search3

That model is valuable for cloud providers because it means integrations can ship independently of Waypoint core releases, and they can be versioned, tested, and distributed like other build/deploy tooling.

Security and operational considerations (because “waypoint up” should not equal “ship it and pray”)

Whenever you introduce a deployment plugin, you’re introducing a new path to production. That needs guardrails.

Credential scope and blast radius

If the plugin uses Scaleway API keys loaded from a default profile, you should think carefully about:

  • Using dedicated deploy tokens rather than personal tokens
  • Restricting tokens to the minimum necessary permissions
  • Separating dev/stage/prod tokens and namespaces

Even in “initial support,” you can set up a decent security posture if you treat Waypoint deployments as production operations and not as a convenience feature.

Networking, privacy, and exposure defaults

Scaleway’s Serverless Containers API notes that containers are public by default and can be configured as private or public via a privacy setting. Calling a private container without authentication yields HTTP 403. citeturn1search1

That means your deployment workflow should explicitly decide:

  • Which services are public endpoints vs. internal-only
  • How authentication is enforced for private services
  • How secrets are passed (environment variables vs. secret managers)

If the plugin’s initial configuration surface doesn’t expose all privacy and networking options, you may need to complement it with IaC (Terraform/OpenTofu) or API-based configuration steps.

Observability and logs

Scaleway notes that container logs are sent to the project’s Cockpit and can be queried via Grafana/Loki. citeturn1search1

That’s good news, but you should still plan for:

  • correlation IDs and structured logging in your app
  • alerting on error rates/latency
  • deployment event logging (who deployed what, when)

The plugin simplifies deployment; it doesn’t replace operational hygiene.

Practical use cases where Scaleway + Waypoint makes sense

1) Small teams that want “serverless ergonomics” with container flexibility

Startups and small product teams often land in the “Kubernetes is a lot” camp, but they still want a container-based workflow for portability. Serverless containers plus a standardized deployment interface (Waypoint) can be an appealing combo: developers ship a container, and the platform handles scaling behavior like scaling to zero. citeturn1search1turn6search0

2) Platform teams standardizing developer experience across targets

If your org deploys some workloads to Kubernetes, some to ECS, and some to serverless containers (because reality), a consistent waypoint.hcl-driven flow can reduce cognitive load. Waypoint was built to hide target differences behind plugins. citeturn0search1turn0search5

3) Event-driven backends and scheduled jobs

Scaleway Serverless Containers supports HTTP triggers and CRON triggers. citeturn1search1

That’s a natural fit for workloads like:

  • webhooks and lightweight APIs
  • scheduled data sync jobs
  • on-demand report generation
  • ingestion pipelines that don’t need always-on servers

With Waypoint in the mix, the deployment of those services can be standardized, leaving teams to focus on code rather than “which CLI flags do I need today?”

Comparisons: Waypoint plugin vs. “just use CI” vs. “just use Terraform”

CI-only approach (GitHub Actions, etc.)

Pros: flexible, ubiquitous, easy to enforce checks and approvals.
Cons: every platform target tends to create its own pipeline template; developer workflows differ per target.

The existence of a GitHub Action for deploying to Scaleway Serverless Containers shows this approach is already viable. citeturn1search2

Terraform/OpenTofu approach

Pros: infrastructure state management, repeatable environments, policy-as-code integration.
Cons: Terraform is not a developer-friendly “inner loop” deploy tool; coupling image deploys to infra state can get awkward.

Scaleway’s Waypoint tutorial explicitly calls out Terraform/OpenTofu as part of a broader demo setup, which hints at the “IaC for infra, Waypoint for app deploy” division of responsibilities. citeturn6search0

Waypoint plugin approach

Pros: consistent workflow, target abstraction, better local developer experience.
Cons: another tool to maintain; “initial support” may not cover all advanced platform features; you still need CI/IaC for governance.

The sweet spot is often combining them: Terraform/OpenTofu provisions namespaces, IAM, and networking; CI builds and scans images; Waypoint deploys and manages releases in a standardized interface.

What to watch next: likely directions for Scaleway’s Waypoint integration

Because Scaleway explicitly calls this “initial” support and currently documents only one plugin (container), the obvious next steps would be expansions that reduce the number of “other tools required” in the pipeline.

Potential areas of evolution (speculative, but grounded in how Waypoint works):

  • Registry integration improvements (smoother push to Scaleway registry)
  • Release management features (rollbacks, traffic switching semantics where applicable)
  • More configuration surface for container settings (privacy, concurrency, resources)
  • Better environment promotion patterns across multiple namespaces/regions

Whether these land as improvements to the existing plugin or as additional plugins depends on how Scaleway chooses to map its product surface to Waypoint’s plugin types.

Conclusion: small changelog note, big DX implications

Scaleway’s “initial support for Waypoint plugin” is the kind of change that doesn’t make a splashy keynote slide, but it does something more valuable: it reduces friction for developers shipping real workloads.

If you’re a Scaleway customer already using Serverless Containers, Waypoint support adds another deployment option that can be cleaner than hand-rolled scripting. If you’re a Waypoint user evaluating deployment targets, Scaleway just got more attractive—especially if you like the “scale to zero” economics and want to avoid running a full cluster.

Just remember the golden rule of “initial support”: it’s not a promise of completeness, it’s a promise of a starting point. The good news is that starting points are exactly where most successful platform tooling stories begin—right before someone automates away a thousand tiny annoyances and calls it “developer experience.”

Sources

Bas Dorland, Technology Journalist & Founder of dorland.org