Scaleway Containers Gets Initial Support for a HashiCorp Waypoint Plugin: What It Means for Serverless Deployments

AI generated image for Scaleway Containers Gets Initial Support for a HashiCorp Waypoint Plugin: What It Means for Serverless Deployments

Scaleway quietly did something that will make a certain class of developers disproportionately happy: it added initial support for a HashiCorp Waypoint plugin in its Containers product changelog. That sounds like a small line item—and it is—but it also signals a bigger theme: cloud platforms keep trying to make “deploying an app” feel boringly consistent, even when the underlying infrastructure is anything but.

The RSS item you provided points to Scaleway’s changelog entry titled “Containers | Initial support for Waypoint plugin”. The original source is Scaleway’s documentation changelog page, and the entry is published by Scaleway as part of its official product updates. You can find it here: Scaleway changelog – Initial support for Waypoint plugin.

Because changelog entries are typically short, the real story is in what “initial support” usually means in practice: there’s now a supported path—via a Waypoint plugin—to deploy to Scaleway Serverless Containers using Waypoint’s workflow and configuration file (the waypoint.hcl). Scaleway also maintains a documentation page describing how to configure and use its Waypoint plugin(s), currently focused on a container plugin. citeturn3search0

Quick refresher: what is Waypoint, and why do people still care?

HashiCorp Waypoint launched with a straightforward pitch: provide a consistent workflow to build, deploy, and release applications across platforms, ideally driven by a single file and a single command. If Kubernetes YAML gives you the same feeling as reading legal terms on a printer driver installer, Waypoint’s value proposition was basically: “Let’s not do that today.” citeturn0search3

Waypoint’s model is typically described as three stages:

  • Build: turn source code into an artifact (often a container image)
  • Deploy: stage that artifact onto a target platform
  • Release: make it live (or switch traffic to it) in the platform’s preferred way

Under the hood, Waypoint is built to be extensible via a plugin system, which is exactly where Scaleway is now showing up. citeturn0search3turn3search7

One important bit of context: the open-source hashicorp/waypoint repository was archived in January 2024, which affects how some teams think about long-term adoption. In practice, that doesn’t erase Waypoint’s usefulness, but it does change the calculus: organizations will be more selective, and they’ll want to see vendor commitment (documentation, maintenance, releases, compatibility) before standardizing on it. citeturn4search2

What Scaleway is actually adding: a Waypoint deployment target for Serverless Containers

Scaleway’s Serverless Containers is a “container as a service” offering designed to run container workloads without the user managing servers, and with features like scaling up/down and scaling to zero. Scaleway’s own API documentation describes the product as enabling users to deploy serverless workloads and only pay for resources used while containers are running. citeturn3search9

So what does “Waypoint plugin support” imply? It means Waypoint can now talk to Scaleway’s Serverless Containers in a first-class way, instead of you duct-taping a deployment using generic scripts.

Scaleway’s documentation (reviewed July 21, 2025) explains that Scaleway provides Waypoint plugins and that currently the only plugin available is container. It also shows how to install it and how to reference it in a waypoint.hcl deploy block. citeturn3search0

A practical feel for the workflow

In Scaleway’s described flow, you’d typically:

  • Build your app into a container image (Waypoint can do this via Docker/buildpacks depending on your setup)
  • Push to a registry (Scaleway has its own Container Registry, but you can also use public registries depending on your model)
  • Use Waypoint to deploy to Scaleway Serverless Containers via the plugin

Scaleway’s tutorial includes a usage snippet where the deploy stage uses a plugin named scaleway-container, with parameters like port, namespace_id, and region. That suggests the plugin’s primary job is: take an image artifact and create/update a Serverless Containers deployment within a given namespace/region. citeturn3search0

Even without getting lost in the weeds, the mental model is simple: Waypoint becomes your “developer-facing deployment CLI,” while Scaleway remains the “platform that actually runs the container.”

Why this matters in 2026: developer experience is the new price-performance ratio

Cloud providers love to compete on price-performance, but increasingly they’re also competing on time-to-deploy and cognitive load. Serverless containers are popular precisely because they try to give you the container packaging model without the constant babysitting that comes with clusters.

Scaleway’s own positioning for Serverless Containers is “run containers with a single command,” and it highlights scaling and reduced infrastructure management as core benefits. citeturn5view1

Waypoint overlaps with that same promise, but at a higher abstraction level: “run your deployment workflow with a single command (waypoint up) across targets.” citeturn0search3

Put them together and you get a nice alignment:

  • Waypoint standardizes the developer workflow.
  • Scaleway Serverless Containers standardizes the runtime environment for containers (with scaling-to-zero and managed operations).

This is especially relevant for teams that want to avoid a Kubernetes dependency for smaller services, internal tools, cron-driven jobs, or spiky workloads—but still want something more structured than “a folder of bash scripts and vibes.”

“Initial support” usually means: expect rough edges (and here are the likely ones)

Changelog phrasing is telling. “Initial support” is rarely shorthand for “feature-complete and battle-tested.” It often means the plugin can deploy successfully, but advanced platform features may not be mapped yet. Based on how serverless container products work and what Scaleway exposes via its API, here are the areas that typically mature over time:

  • Identity and secrets: mapping credentials, environment variables, secret injection, and rotation patterns cleanly through Waypoint config.
  • Networking: private networking attachments, inbound auth modes (public vs private endpoints), and domain management.
  • Release mechanics: whether “release” is distinct from “deploy” in a serverless container product, and how traffic switching/rollbacks are represented.
  • Observability: how logs, metrics, and traces are discovered from the Waypoint UI/CLI versus the provider console.

Scaleway’s API documentation for Serverless Containers includes details about triggers (HTTP and CRON), privacy modes (public/private), and logging via its Cockpit observability stack (Grafana/Loki). Those are the sorts of platform concepts a plugin may progressively expose in a smoother configuration experience. citeturn4search3

How it compares: Waypoint vs “just use the provider’s CLI/API” vs other deployment tools

1) Provider console/CLI/API

This is the baseline. Scaleway has a documented API for Serverless Containers and encourages using it directly or via frameworks. Direct API/CLI use gives you full control, but it’s also where teams reinvent the same deployment pipeline repeatedly. citeturn3search9

2) Serverless Framework plugin approach

Scaleway has long leaned into the Serverless Framework ecosystem with a plugin that supports both functions and containers and defines resources in serverless.yml. This appeals to teams already standardized on that tooling. citeturn0search1turn0search5

3) Waypoint plugin approach

Waypoint is attractive when you want a consistent “developer command” across multiple targets. If a team deploys some workloads to Kubernetes, some to ECS, and some to serverless containers, Waypoint’s promise is: one workflow, multiple platforms. Scaleway joining that plugin ecosystem is essentially Scaleway saying: “Sure, we’ll be one of your targets.” citeturn0search3turn0search6

4) Terraform/OpenTofu + CI pipeline

Many teams use IaC for provisioning and a separate pipeline for build+deploy. Interestingly, Scaleway’s Waypoint tutorial prerequisites explicitly mention Terraform/OpenTofu, suggesting a common pattern: use IaC to create the namespace/infra scaffolding, then use Waypoint for build/deploy iteration. citeturn3search0

Industry context: why a serverless containers target is a sensible bet

Serverless containers sit in the “middle lane” between functions and Kubernetes:

  • Compared to functions, you get fewer runtime constraints and more control (bring any container image that listens on the platform port).
  • Compared to Kubernetes, you outsource a lot of operational work and often gain simpler scaling-to-zero economics.

Scaleway markets Serverless Containers as a way to deploy “any containerized web application as long as it listens on the PORT environment variable,” and it emphasizes CRON and HTTP triggers, custom domains, and managed scaling. citeturn5view1

That positioning lines up well with Waypoint’s original goal: get apps from code to a running URL quickly, across platforms. citeturn0search3

What teams can do with this today (realistic use cases)

Use case 1: internal tools with spiky usage

Think: an admin dashboard used a few times per day, or a support tool that gets hammered during incidents and then sits idle. Serverless containers’ scaling-to-zero can save money, but “deployment ceremony” can be a tax. Waypoint can reduce that tax, especially for developer-driven deployment.

Use case 2: scheduled jobs that need full container flexibility

Scaleway’s API documentation explains that CRON triggers exist and are implemented under the hood by Kubernetes jobs sending HTTP POST requests to your container. If you have batch jobs, ETL tasks, or periodic reporting, serverless containers can run them without you managing a cluster directly. A Waypoint plugin can make iterative deployment easier. citeturn4search3

Use case 3: “Kubernetes later” migration path

Many teams start on something simpler and move to Kubernetes only when necessary. Scaleway itself pitches a migration story “from Kubernetes or Instances to Serverless Containers,” underscoring that it sees serverless containers as a simplification step for some workloads. Waypoint’s cross-platform approach can help keep deployment workflows steady even as the runtime target changes. citeturn4search0

Security and operational considerations (the un-fun stuff that matters)

When you add a deployment plugin, you’re adding a new control plane component in your workflow. The basic questions a security-minded team will ask:

  • Where do credentials live? Scaleway’s tutorial notes API keys are loaded from Scaleway’s default config profile and can be overridden via environment variables. That’s convenient, but it also means you need to align on secrets management in CI and on developer machines. citeturn3search0

  • What’s the blast radius? Ensure the key used by the plugin has least-privilege access (project scoping, namespace scoping if available).
  • How do you audit deployments? Decide whether your “source of truth” is Waypoint logs, Scaleway console activity, or both.

On observability, Scaleway states container logs are sent to Cockpit and can be viewed in Grafana (and queried via Loki). That’s great—but teams should decide how that integrates with their existing monitoring stack, and whether Waypoint’s UX adds anything beyond a thin deployment wrapper. citeturn4search3

So, is this a big deal?

For the average developer? Probably not. For teams that already like Waypoint’s workflow—or that want a single-file deployment description and a predictable CLI experience—this is meaningful. The more platforms that become Waypoint targets, the more viable Waypoint’s “consistent workflow” promise becomes. citeturn0search3

For Scaleway, it’s a developer-experience play that complements its existing ecosystem integrations (like its Serverless Framework plugin). In a world where every cloud offers roughly the same primitive building blocks, the provider that makes you feel productive fastest often wins the next workload.

What to watch next

  • Plugin maturity: whether Scaleway expands beyond “initial support” into richer configuration (domains, triggers, private networking, secrets ergonomics).
  • Maintenance signals: release cadence, compatibility notes, and the health of the plugin’s repository and docs.
  • Workflow fit: whether teams standardize on Waypoint for day-2 operations (logs/exec/status) or use it only for deployment.

In the meantime, if you’re already using Scaleway Serverless Containers and your team has Waypoint muscle memory, “initial support” is often enough to start experimenting—just don’t confuse “works” with “finished.”

Sources

Bas Dorland, Technology Journalist & Founder of dorland.org