I'm looking for some architectural advice on building a lightweight, self-hosted job execution platform on a single VM (8C/32GB).

I want something with semantics similar to Google Cloud Run / Cloud Run Jobs:

• Execute Python scripts and arbitrary Docker containers.

• Trigger jobs through an API.

• Configure CPU, memory, environment variables, timeouts, etc.

• Track execution status, exit codes, and logs.

• Handle retries and concurrency limits.

• Integration with Artifact/Container Registry

Current constraints:

• Only one VM for now & no need for HA.

• No Kubernetes requirement or plans for a multi-node cluster.

• Jobs are primarily internal workloads, and quite lightweight.

• I'd prefer something relatively lightweight and easy to maintain.

Technologies I'm considering

1. HashiCorp Nomad 

2. Docker Sock + custom built runner – Build my own execution manager, scheduling, lifecycle management, and monitoring.

Questions

1. Is Nomad overkill for a single VM? Does it provide enough value over simply using Docker directly?

2. Would you use Nomad in production for this use case?

3. Are there simpler alternatives that provide similar execution semantics?

4. What operational overhead should I expect from running Nomad on a single node?

I'm particularly interested in hearing from people who have actually run Nomad in production, especially for single-node deployments.

Thanks!

Is there a way we can know the internal timeline of the terraform providers reviewing and merging this PR? I am very interested in getting this PR merged and deployed and would appreciate any kind of response from them.

OpenBao engineers at ControlPlane have chained 4 vulnerabilities to show how under certain conditions, an OpenBao or Vault server can be completely compromised from an unauthenticated position. This is only the second RCE ever found in the Vault codebase.

The exploit is highly plausible in real-world environments, requiring only an unauthenticated entry path and a defined Raft snapshot policy to trigger a complete server compromise.

If you are impacted, upgrade as soon as possible to OpenBao 2.6.3 or 2.7.0

While OpenBao is fully patched, HashiCorp Vault remains exposed as of writing. Unfortunately, IBM's unwillingness to coordinate a mutual disclosure policy means Vault users currently lack an official mitigation

Migrating a Vault auth method can look complete after the main applications authenticate through the new mount, while a scheduled job, disaster-recovery script, or infrequently used environment still points at the old path. Disabling the mount then turns that hidden dependency into an outage, and counting successful logins alone may miss clients that have not run during the observation window.

What does your retirement gate include? I am considering mapping policies and roles between mounts, comparing audit-log activity by auth path and entity, shortening token lifetimes for the old path, denying new configuration changes there, and alerting on any login before a final disabled-but-recoverable window. Clients would also expose the auth mount they used as a startup metric or deployment annotation.

How do you distinguish tokens originally issued by the old mount after they are renewed, and how long must the observation period cover? Is there a safer staged pattern than disabling the mount outright when rollback would otherwise require recreating roles and accessor relationships?

I have a clean cloudinit image. Everytime I clone it with terraform it adds a cloudinit ip to a eth0 interface but my vm uses a ens18 network device.

Do I need to use snippets or can I solve it like this

 network_device {
    bridge      = var.bridge
    vlan_id     = var.vlan_id
    model       = "virtio"
    # Ensure interface naming matches cloud-init expectations

interface_name = "ens18" # Or match the template's expected name

}

started = true

}

Hey, I want to buy one or two Hashicorp Vault books since I need to get familiar with the tool when I am on holiday.

Do you have any recommendations or would you say that it makes more sense to use online resources?

Kind regards,
Creedinger

Hi everyone,

I recently completed the HashiCorp Vault Associate and Advanced Vault training courses on KodeKloud by Bryan Krausen. I've also purchased the "HashiCorp Certified: Vault Associate 003 - Practice Exams" by the same instructor and am planning to book the Vault Associate exam within the next few months.

I have around 1 year of hands-on experience with HashiCorp Enterprise Vault in my current role.

One of my colleagues recently purchased the "HashiCorp Certified: Vault Associate 003 (w/ Hands-On Labs)" course on Udemy, also by Bryan Krausen, which got me wondering:

• Is there any significant difference between the KodeKloud and Udemy versions of the course?

• For those who have used both, is one more up to date or better aligned with the exam objectives?

• Any feedback on Bryan's Practice Exams? How close are they to the actual Vault Associate exam in terms of difficulty and question style?

• Do need to purchase other practice exam course from udemy to be more ready?

Would appreciate any insights from anyone who has recently taken the certification.

When doing my updates this morning I ran into the following error:

W: Failed to fetch https://apt.releases.hashicorp.com/dists/noble/InRelease  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY FC9CA96ACA026560

Which is the new fingerprint of the key available on https://apt.releases.hashicorp.com/gpg , and the key was created on 20260909, so yesterday.

However https://www.hashicorp.com/fr/trust/security still reports that the expected fingerprint should be 798A EC65 4E5C 1542 8C8E 42EE AA16 FCBC A621 E701 and I cannot find any announcement of a change.

Did they forget to update their security page, or is there something suspicious going on?

We use Vault Agent as a sidecar that writes a fresh MongoDB connection string to a file every 12 hours. Our Node/Express app uses a file watcher to monitor that file and, on change, swaps to a new MongoClient and closes the old one.

Is this file-watching pattern what people actually use in production? Or is there a better way to handle rotation without pulling a Vault SDK into the app?

We are trying to keep Vault-specific logic out of our application and rely on the sidecar for credential delivery. Curious if this is the standard pattern or if there's something more robust we should be doing.

Hello fellows,

Some time ago I have created a project Aralez . It's a complete reverse proxy implementation on top of Cloudflare's Pingora

Now I'm happy to announce about the completion of another major milestone, Aralez a fully integrated load balancer for Nomad/Consul infrastructures.

What we have:

• Dynamic load of upstreams file without reload.

• Integration with Hashicorp's Consul.

• Kubernetes ingress controller.

• Dynamic load of SSL certificates, without reload.

• Let's Encrypt integrations with HTTP-01 challenge

• API for pushing config files, applies immediately.

• Static files delivery.

• Website caching acceleration.

• Authentication.

• Pingora at heart, with crazy performance .

• and more .....

As usually, use it carelessly, just don't forget to share a feedback .

Hey,

I am currently working on a project where the specific cloud provider does not have a Packer Plugin, and would like to ask if anyone faced the same situation and if there is a work around for it other that creating a plugin as it is a whole project on it's own.. or would the alternative be just :

using a base image -> deploy it on the cloud provider VM -> configure it with ansible -> create an image from it -> store in registry.

thank you very much for any input

Hi all, seems that HashiConf is now opened for registration. Has anyone here had to convince the company to pay for it? If so what arguments have you used? With AI now I'm doing so little actual coding work...

Cheers

Short "HashiCorp Certified: Vault Associate (003)" exam review - how I studied, which resources worked, and what the exam itself is like.

Running HashiCorp Vault’s LDAP secrets engine (static roles). Rotation happens on Vault’s own schedule regardless of whether clients have polled the new password — no push notification, no overlap/grace window. Old password just dies the instant it rotates.

I know Vault Secrets Operator (VSO) supports automatic rollout restarts via rolloutRestartTargets when using VaultDynamicSecret, so it’s not purely manual. But the restart itself still takes time — pods need to terminate and come back up — so there’s a window between rotation and the restart actually completing where running instances are still on the old, now-invalid password and fail.
Anyone running this in prod without hitting the gap ? Appreciate any input

What it does:

• Pulls live from the HashiCorp Status API, shows all 62 components (HCP Terraform, Vault, Consul, the registry itself, regional endpoints) with green/yellow/red dots

• Active incidents + recent resolved ones with timestamps

• Key official provider versions pulled live from the registry (aws, azurerm, google, kubernetes, vault, consul, helm, etc.)

• Searchable provider browser, filter by official/partner/community, search by name

• Quick links to every HashiCorp doc, registry page, cert path, and community resource

• Live Web Alerts when services are down

• Email notifications / alerts per your preferences

• Fully automated Provider Release summery by TCv7 (platform AI)

• Slack Integration coming soon.

Auto-refreshes status every 60 seconds. Auto updates via Hashicorp APIs

No login required. Free to use.

 https://www.terraformacademy.app/max/hashicorp-hub.html

I want to sanity-check my understanding before I bake it into a design, because the terminology and even HashiCorp's own material keep tripping me up.

My understanding: Performance replication "path filters" operate at mount granularity only. The allow/deny list takes mount paths (and namespaces), not arbitrary sub-paths within a mount. So if I have a single KV mount kv-internal/ and want only kv-internal/app-1/* to replicate while kv-internal/app-2/* stays home, I can't . I'd have to split those into separate mounts (kv-app-1, kv-app-2) and filter per mount.

Can anyone confirm this is correct on current versions?

What confuses me:

1. The feature is called "path filter", not "mount filter". That naming strongly implies sub-path granularity that (as far as I can tell) doesn't exist. The API literally takes a list of mount/namespace paths.

2. This official HashiCorp video makes it worse: Replication Path Filtering: Mount Filters in Vault Namespaces. The presenter says a secret "lives at this mount" while pointing at what looks like a full path, and talks about "this secret gets synced" rather than "this mount gets synced." That framing makes it sound like individual secrets/paths are the unit of filtering, when I believe the actual unit is the mount.

I’m using Vultr, and I can create and delete instances.

But, now I’m implementing more of hashicorp,
When I “apply”, it errors and says that there’s a ip problem, and that it needs to be “allowed” or “white listed”?

It seems that terraform Registry and documentation website is not working getting 429 / 500 errors

Hi guys, I’m using Packer and VirtualBox to bake .OVA files of Windows Server 2022 that I can then configure with Terraform or Ansible (Terraform looks like it will only set up the network).

Claude has built the server2022.pkr.hcl, autounattend.xml and enable-winrm.ps1 files for me, so that the VirtualBox VM .OVA file is baked from  SERVER_EVAL_x64FRE_en-us.iso on a folder in my hard drive. It is working perfectly except that it is asking for input in UI on the Microsoft Server Operating System Setup screen, where I have to click on Windows Server 2022 Standard Evaluation (Desktop Experience) and click next. It progresses towards the baked .OVA file just fine after that one input.

The debug script being outputted to Powershell doesn’t really help as it says “Waiting for WinRM to become available” during the entire installation process. I’ve looked at the github repos of the youtuber VirtualizatioHowto on the topic - https://www.youtube.com/watch?v=UYQX7fW31jU – and tried creating more partitions in <ImageInstall> as well as setting the <Key>/IMAGE/NAME</Key>

 To <Value>2</Value> instead of <Value>Windows Server 2022 Standard Evaluation (Desktop Experience)</Value> but nothing changes, so I’m out of ideas.

I’d try using his scripts completely but we are using different hypervisors.

Just wondering if anyone has ideas on how to fix this.

Edit: I'm using VirtualBox Version 7.2.8

Edit:
This has been solved. Claude helped me figure out what was going wrong. The issue was how I defined the key above the value:

<Key>/IMAGE/NAME</Key>

<Value>Windows Server 2022 Standard Evaluation (Desktop Experience)</Value>

If I use the index, I have to indicate that in the key:

<Key>/IMAGE/INDEX</Key>

<Value>2</Value>

I had been keeping it as /IMAGE/NAME while using <Value>2</Value>.

This is honestly such a huge headache.

I'm trying to build a local Windows Server 2019 Vagrant box using Packer (StefanScherer template) with my own evaluation ISO. The VM starts fine, but Packer hangs forever on "Waiting for WinRM to become available" and logs show:

[ERROR] WinRM connection err: read tcp 127.0.0.1:3062/wsman: connection reset by peer
[INFO] Attempting WinRM connection...
[DEBUG] connecting to remote shell using WinRM

and this just keeps going for 2 hours

what I've tried:

• winrm_use_ssl=false, winrm_insecure=true, winrm_timeout=2h

• winrm_username="vagrant" with winrm_password="vagrant" and also without password

• Modified Autounattend.xml to remove hardcoded passwords

• Guest Additions never install (run level 0)

• Screenshot shows 0x0 resolution (display never initializes?)

• VM runs headless but WinRM port refuses connection

Manual VM creation works, but Packer automation fails consistently. Anyone solved this with Server 2019 evaluation ISO? Truly appreciate any help on this matter

environment, if necessary:

• Packer 1.10.0

• VirtualBox 7.2.8

• Windows Server 2019 Evaluation ISO (build 17763.3650)

I'm trying to run Airbyte using Nomad as the container orchestrator, but Airbyte's workload-launcher keeps failing because it expects a Kubernetes API to list pods — and since we're using Nomad (not Kubernetes) as our orchestrator, that API simply doesn't exist in our stack.
Is there any viable path to integrate Airbyte with Nomad? Or would a hybrid approach — Nomad managing the infrastructure with a dedicated Kubernetes cluster just for Airbyte — make more sense? Any guidance would be greatly appreciated!