Scaleway Containers Gets Initial Support for a HashiCorp Waypoint Plugin: What It Means for Serverless Deployments (and Your Sanity)

AI generated image for Scaleway Containers Gets Initial Support for a HashiCorp Waypoint Plugin: What It Means for Serverless Deployments (and Your Sanity)

Scaleway slipped a very developer-friendly item into its documentation changelog: initial support for a Waypoint plugin for its Containers product. In plain English, that means teams who still like HashiCorp’s “waypoint up” workflow can now point it at Scaleway Serverless Containers with a first-party plugin and a repeatable configuration file, instead of stitching together bespoke scripts and hoping nobody changes an API parameter on a Friday afternoon.

This update is referenced in Scaleway’s documentation changelog entry Containers | Initial support for Waypoint plugin (the RSS item you provided). The changelog itself doesn’t spill all the tea on implementation details, but Scaleway’s own tutorial and the plugin repository fill in the practical “how do I actually use this?” story. We’ll connect those dots, then step back and ask the more interesting questions: why now, who benefits, and is Waypoint still a sensible tool in 2026?

Quick refresher: What is Waypoint (and why did anyone care)?

HashiCorp Waypoint launched with an ambitious promise: give developers a consistent workflow to build, deploy, and release applications across multiple platforms—Kubernetes, Nomad, ECS, Cloud Run, Azure Container Instances, and more—without requiring every team to become an expert in each platform’s YAML dialect and deployment rituals. The “magic” was a combination of a declarative config file (waypoint.hcl), a CLI experience designed around waypoint up, and a plugin system to integrate with build/deploy targets. citeturn3search11

In other words, Waypoint tried to be the unifying layer between “I have code” and “I have a running service” in a world where we already had CI systems, container registries, and more deployment targets than any human asked for.

Waypoint also leaned into a philosophy that still resonates: developers prefer simple, repeatable interfaces, and they’d rather not maintain an ever-growing pile of custom scripts for each environment. Whether Waypoint achieved that universally is… debated (the DevOps internet has opinions). But the idea—standardized deployment ergonomics—never really went away.

Where Scaleway fits: Serverless Containers, but make it European

Scaleway’s Serverless Containers is positioned as a managed service for running stateless containerized web apps and services without managing servers. Scaleway describes it as Knative-based and built to scale up and down on demand—including scaling to zero—so you can run workloads with sporadic traffic economically. citeturn4view1turn4view3

On its product page, Scaleway emphasizes that you can run “any containerized web application as long as it listens on the PORT environment variable,” and that you typically push an image to Scaleway’s registry and deploy it using Serverless Containers. citeturn4view1

This places Scaleway’s Containers product in the same broad category as services like Google Cloud Run: container-first, serverless-ish, with an operational model that prioritizes minimal infrastructure babysitting. The key difference is that Scaleway is often chosen for EU footprint, pricing, and sovereignty preferences, especially for teams who prefer not to anchor everything to hyperscalers.

The news: “Initial support for Waypoint plugin” — what actually changed?

The RSS title you provided points to Scaleway’s docs changelog anchor: Containers | Initial support for Waypoint plugin. That entry indicates that Scaleway’s Containers service now has initial integration support via a Waypoint plugin.

While the changelog page itself is minimalist in the excerpt the public docs UI exposes, Scaleway has a dedicated tutorial—reviewed on July 21, 2025—that explains how to install and use Scaleway’s Waypoint plugin to deploy to Scaleway Serverless Containers. citeturn4view0

That tutorial is essentially the operational manual for the changelog entry: how to obtain the plugin binaries, where to place them, what to put in waypoint.hcl, and how to run the workflow end-to-end. citeturn4view0

Meet the plugin: scaleway/waypoint-plugin-scaleway

Scaleway maintains an open repository on GitHub called scaleway/waypoint-plugin-scaleway. The README is refreshingly direct: “Plugins for waypoint that add support for Scaleway. Currently, the only plugin available is container.” citeturn6view1

That “container” plugin is the relevant piece here: it acts as a Waypoint deploy plugin that targets Scaleway’s Serverless Containers platform (Scaleway calls the deployment target “Serverless containers” in their tutorial). citeturn4view0turn6view1

Release state: why “initial support” matters

The repository’s release history (as visible on GitHub) shows at least one tagged release: v0.1.0 dated March 3, 2023. citeturn6view0

This doesn’t mean the integration is new in absolute terms—there has been code in the wild for a while—but it does suggest that Scaleway is formalizing support and pointing people to it more explicitly through product changelogs and updated docs. “Initial support” reads like a signal: this is supported enough to document, but still early enough that you should not treat it like an immutable, enterprise-grade interface carved into granite.

How the workflow looks: Waypoint + Scaleway Containers in practice

Scaleway’s tutorial lays out two installation paths:

  • Install from releases: download a zip file and unzip it into Waypoint’s plugin directory.
  • Build from source: clone the repo and run make all install.

The “from releases” approach uses a local plugin directory under the Waypoint config path. Scaleway’s docs show unzipping the archive into ~/.config/.waypoint/plugins/. citeturn4view0

Then your waypoint.hcl gets a deploy stanza that looks like this (adapted from Scaleway’s documentation): citeturn4view0

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

There are a few important details embedded in those few lines:

  • You deploy into a namespace: Scaleway’s Serverless Containers uses namespaces as a fundamental organizational unit; you provide the namespace_id. citeturn4view0turn4view3
  • You pick a region: the example uses fr-par (Paris region). citeturn4view0
  • There’s an explicit port: the plugin config includes a port field, and Scaleway’s platform expects the workload to listen on the PORT env var. In practice, most teams align these values so the container behaves consistently across local and serverless environments. citeturn4view1turn4view0

Authentication: it uses Scaleway’s config and environment variables

According to Scaleway’s tutorial and the plugin repository README, the plugin loads API keys from Scaleway’s default config profile and allows overriding via environment variables. citeturn4view0turn6view1

That design is a good sign: it matches how many teams already work with cloud CLIs—use a standard credential configuration locally, override in CI using environment variables, and avoid checking secrets into config files (because you enjoy not having incident response calls).

Why this matters in 2026: platform engineering is tired, and “glue work” is expensive

At first glance, a Waypoint plugin sounds like a niche feature for a niche tool. But there are broader industry dynamics that make this a quietly strategic move.

1) Platform teams want paved roads, not infinite choose-your-own-adventure

The “platform engineering” movement has largely been about creating standardized internal developer experiences (IDP). Whether you use Backstage, Portals, custom CLIs, or GitOps workflows, the motivation is the same: reduce cognitive load and stop reinventing deployments per team.

Waypoint’s entire pitch has always been to provide a “golden path” deployment workflow via a single config file and a consistent CLI. So if you’re Scaleway, adding a Waypoint plugin is a way of saying: “If you already standardized on this workflow, you can keep it—and still use our serverless container platform.” citeturn3search11turn4view0

2) Serverless containers are increasingly the default for smaller services

Not everything deserves a Kubernetes cluster. Some services are small, sporadic, or operationally boring. Those are exactly the kinds of services that benefit from serverless containers: scale-to-zero, minimal ops, and you only pay for what runs (at least conceptually; every vendor’s billing model has its own personality quirks).

Scaleway’s API documentation highlights scaling characteristics, including automated scaling and scaling to zero. citeturn4view3

When a platform behaves like that, the remaining friction is usually: building images, pushing them, deploying updates, and wiring environment variables/secrets. That is “deployment glue,” and Waypoint is one of several tools trying to make that glue less sticky.

3) European cloud competition is about developer tooling as much as raw compute

Compute is table stakes. Differentiation increasingly comes from how quickly developers can ship reliably. Hyperscalers have invested massively in DX (developer experience): managed build services, opinionated deployment pipelines, integrated monitoring, etc.

Smaller cloud providers can’t always match every managed service, but they can win with smart integrations into popular workflows. A Waypoint plugin is one such integration, and it complements other automation approaches like Scaleway’s CLI and API-driven deployments. citeturn0search11turn4view3

Under the hood (conceptually): what a deploy plugin typically does

Scaleway’s public docs don’t publish a deep “plugin internals” walkthrough in the tutorial, and GitHub’s web UI is not the best venue for reading every line of Go code. But we can outline what a Waypoint deploy plugin like scaleway-container generally has to handle, based on Waypoint’s architecture and Scaleway’s Serverless Containers API model:

  • Image coordination: Waypoint’s build step produces an image, and the deploy plugin needs to reference a registry image location. Scaleway’s docs show logging into Scaleway Container Registry with Docker using a secret key, which indicates a typical workflow: build locally/CI, push to Scaleway registry, then deploy the registry image. citeturn4view0turn4view1
  • Namespace and region targeting: the deploy plugin needs to map Waypoint configuration to Scaleway’s namespace/region model. citeturn4view0turn4view3
  • Service creation/update: deploy to serverless containers usually means calling APIs to create or update a container definition (CPU/memory, env vars, scaling), then triggering a deploy. Scaleway’s API docs illustrate the idea of creating a container with configuration and then deploying it. citeturn4view3
  • Status and URLs: a developer-friendly deploy experience returns an endpoint URL and some health/status info. Scaleway’s API model includes retrieving container details including endpoints. citeturn4view3

So “initial support” is not just a checkbox. It’s an integration that has to keep pace with API evolution, region expansion, and the occasionally spicy realities of container platform behavior (cold starts, scaling semantics, and all the fun edge cases where ‘stateless’ meets ‘but I really wanted a cache’).

A practical example: deploying a small web API the “Waypoint way”

Let’s turn this into a relatable scenario. Imagine you run a small internal service: a webhook receiver that validates payload signatures and forwards events into a queue. It’s mostly idle, with occasional spikes when a partner does a bulk export. That is practically a poster child for serverless containers.

Without a Waypoint plugin

  • Build image in CI
  • Authenticate to Scaleway registry
  • Push image
  • Call Scaleway API or CLI to update container config
  • Trigger deploy
  • Poll for status, fetch endpoint, update docs/monitoring

This is fine—until you have 12 services, 3 teams, and 2 different “standard” scripts written by 4 different people over 18 months.

With Waypoint + Scaleway plugin

The goal is fewer moving parts in your deployment interface: the deploy target is encoded in waypoint.hcl, and the execution is the same everywhere:

  • waypoint init (once per project)
  • waypoint up (build + deploy)

Scaleway’s tutorial explicitly ends with “Build and deploy your application on Scaleway’s Serverless containers” using waypoint up. citeturn4view0

That’s the big win: one consistent developer ritual, fewer bespoke scripts, and less “tribal knowledge” living in a single engineer’s brain (which, as history shows, is not a reliable storage backend).

How it compares: Waypoint vs GitHub Actions vs Terraform/OpenTofu vs “just use the CLI”

Scaleway’s Waypoint tutorial itself lists prerequisites that include Docker, Terraform or OpenTofu, Waypoint, and jq. citeturn4view0

That’s a subtle but important clue: this integration is not trying to replace infrastructure provisioning. It’s focused on application deployment to an existing container namespace, while you still use IaC to provision foundational pieces like Kubernetes clusters (if needed) and namespaces.

Waypoint vs GitHub Actions

GitHub Actions is a CI/CD runner and workflow engine. It is brilliant at orchestrating steps, but it does not define a single portable “deployment interface” across platforms. You end up writing steps that call vendor CLIs, APIs, or Terraform, and those steps become your interface.

Waypoint is trying to make the interface the project config and the Waypoint CLI, with plugins handling target-specific behavior. That’s a different abstraction layer. If your organization already has strong, standardized pipelines, you may not need Waypoint. But if you have inconsistent deployment patterns across teams, Waypoint can be a “paved road” option—assuming you accept its opinions and limitations.

Waypoint vs Terraform/OpenTofu

Terraform and OpenTofu are infrastructure provisioning tools. You can absolutely deploy workloads with Terraform, but many teams prefer not to tie “deploy new app version” to “infrastructure plan/apply,” because that can blur blast radius and increase cycle time. Scaleway’s tutorial uses Terraform/OpenTofu to set up infrastructure (like a Kubernetes cluster and container namespace), then uses Waypoint to deploy the application. citeturn4view0

Waypoint vs Scaleway API/CLI

Scaleway provides an API for serverless containers and a CLI that can manage container resources. citeturn4view3turn0search11

If you like explicit control and minimal abstraction, the API/CLI route remains solid. The Waypoint plugin mainly helps if you want a higher-level interface and a consistent workflow across environments. Think of it as “less glue code” and “more convention.”

Security and operational considerations (because production is where fun goes to be audited)

Credential handling

Scaleway’s docs and plugin README emphasize that API keys are loaded from Scaleway’s config and can be overridden with environment variables. citeturn4view0turn6view1

For CI systems, environment variables are typically the right move (with secret managers). For local development, a CLI-managed config profile is convenient. The key operational guidance is timeless:

  • Use least privilege keys where possible.
  • Rotate secrets regularly.
  • Prefer short-lived credentials if your environment supports it.

Supply chain and plugin binaries

Installing plugins from GitHub releases is convenient, but it introduces the same questions every binary download introduces:

  • How do you verify the artifact?
  • How do you pin versions?
  • How do you roll out updates safely across developer machines and CI runners?

Scaleway’s tutorial recommends downloading the zip of the “latest version.” In a production environment, “latest” is often a synonym for “surprise.” A safer practice is to pin to a known release (for example, v0.1.0 if that’s what you’ve tested) and upgrade intentionally.

API evolution risk

Serverless platforms evolve. Scaleway’s own serverless containers docs show API behavior changes and deprecations (for example, a deprecated redeploy parameter in an update endpoint, with guidance to use a dedicated deploy method). citeturn9view0

That’s normal—and it’s exactly why “initial support” is worth treating cautiously. If the plugin’s logic depends on behavior that changes, you may need updates. Keep an eye on Scaleway’s containers changelog and the GitHub repo issues/releases.

Is Waypoint “alive” enough to bet on?

This is the awkward question that always pops up with Waypoint: is it still actively developed in open source form, and is HashiCorp still positioning it as a core tool?

From a purely factual standpoint: the Waypoint GitHub repository exists and describes the project as “A tool to build, deploy, and release any application on any platform.” citeturn4view2

But the broader ecosystem sentiment has been mixed over the years, especially as HashiCorp’s strategy has shifted and some capabilities have moved toward hosted offerings. Regardless of where you land on that debate, Scaleway’s decision to document and support a plugin is still meaningful for teams already using Waypoint or evaluating it as part of a standardized developer workflow.

The practical advice: if you’re considering adopting this integration today (April 1, 2026), treat it like any other dependency:

  • Run a proof of concept with one service.
  • Pin versions and document the workflow.
  • Have a fallback path using Scaleway’s CLI/API in case the plugin lags behind platform changes.

What I’d like to see next from Scaleway (a mildly cheeky wishlist)

“Initial support” is a good start, but developer integrations thrive when they’re treated as products, not side quests. Here’s what would make this integration feel fully grown-up:

  • Clear support matrix: which Scaleway regions, container features (custom domains, private networking, cron triggers), and scaling options are supported through the plugin vs needing manual steps.
  • Version compatibility notes: which Waypoint versions are supported, and whether there are known issues with newer/older releases.
  • Examples beyond “hello world”: real-world patterns like blue/green or canary releases, secret injection, and multi-environment configs.
  • CI reference pipelines: an example GitHub Actions or GitLab CI pipeline that pins the plugin and deploys safely.
  • Observability hooks: guidance on how to map Waypoint deployment metadata into Scaleway Cockpit/Grafana dashboards, so you can answer “what changed?” without archaeology.

Scaleway already provides strong building blocks—API-driven serverless containers, CLI tooling, and documentation. citeturn4view3turn0search11 The Waypoint plugin is a logical addition for teams who want a consistent deployment ritual.

Bottom line: small changelog item, big workflow implications

Scaleway’s “Containers | Initial support for Waypoint plugin” update is not the flashiest cloud launch you’ll see this quarter. There’s no new GPU instance or quantum unicorn attached. But it addresses a real pain: how to standardize deployments to a serverless container platform without everyone hand-rolling their own scripts.

If your organization already uses Waypoint—or if you’re exploring ways to reduce deployment complexity across multiple targets—this plugin gives you a pragmatic path to deploy to Scaleway Serverless Containers with a first-party, documented integration.

And if you don’t use Waypoint? You can still appreciate what this signals: Scaleway is investing in developer workflow integrations, not just raw infrastructure. In 2026, that’s often the difference between “a platform you can run on” and “a platform developers actually enjoy using.”

Sources

Note on attribution: The changelog entry is published by Scaleway, and the Waypoint plugin tutorial is maintained within Scaleway’s documentation. The plugin repository is published under the Scaleway GitHub organization.

Bas Dorland, Technology Journalist & Founder of dorland.org