Feature Request: Separate Domain Verification Resource/Action #151

Open
opened 2026-04-05 16:18:58 +02:00 by MrUnknownDE · 0 comments
Owner

Originally created by @listellm on 1/19/2026

Feature Request: Separate Domain Verification Resource/Action

Current Behavior

Domain verification currently requires updating the oneuptime_domain resource's is_verified attribute:

  1. Create domain with is_verified = false → generates domain_verification_text
  2. Create DNS TXT record with verification text
  3. Update domain with is_verified = true → triggers verification

This requires a two-step Terraform apply process and feels unnatural in infrastructure-as-code workflows.

Proposed Solution

Add one of the following approaches:

Option 1: Separate verification resource

resource "oneuptime_domain" "example" {
  project_id = "..."
  domain     = "status.example.com"
}

resource "oneuptime_domain_verification" "example" {
  domain_id = oneuptime_domain.example.id
  
  depends_on = [aws_route53_record.verification_txt]
}

Option 2: Verification action via provider function

resource "oneuptime_domain" "example" {
  project_id = "..."
  domain     = "status.example.com"
}

resource "terraform_data" "verify_domain" {
  input = oneuptime_domain.example.domain_verification_text
  
  provisioner "local-exec" {
    command = "oneuptime domain verify ${oneuptime_domain.example.id}"
  }
  
  depends_on = [aws_route53_record.verification_txt]
}

Option 3: Auto-verify on refresh
Make verification happen automatically when the provider detects DNS TXT record exists during refresh, eliminating the need for manual trigger.

Benefits

  • More intuitive Terraform workflow
  • Single apply after DNS record creation
  • Clearer separation of concerns (creation vs verification)
  • Better aligns with Terraform best practices

Current Workaround

Users must toggle is_verified from false to true in a second apply after DNS propagation.

*Originally created by @listellm on 1/19/2026* ## Feature Request: Separate Domain Verification Resource/Action ### Current Behavior Domain verification currently requires updating the `oneuptime_domain` resource's `is_verified` attribute: 1. Create domain with `is_verified = false` → generates `domain_verification_text` 2. Create DNS TXT record with verification text 3. Update domain with `is_verified = true` → triggers verification This requires a two-step Terraform apply process and feels unnatural in infrastructure-as-code workflows. ### Proposed Solution Add one of the following approaches: **Option 1: Separate verification resource** ```hcl resource "oneuptime_domain" "example" { project_id = "..." domain = "status.example.com" } resource "oneuptime_domain_verification" "example" { domain_id = oneuptime_domain.example.id depends_on = [aws_route53_record.verification_txt] } ``` **Option 2: Verification action via provider function** ```hcl resource "oneuptime_domain" "example" { project_id = "..." domain = "status.example.com" } resource "terraform_data" "verify_domain" { input = oneuptime_domain.example.domain_verification_text provisioner "local-exec" { command = "oneuptime domain verify ${oneuptime_domain.example.id}" } depends_on = [aws_route53_record.verification_txt] } ``` **Option 3: Auto-verify on refresh** Make verification happen automatically when the provider detects DNS TXT record exists during refresh, eliminating the need for manual trigger. ### Benefits - More intuitive Terraform workflow - Single apply after DNS record creation - Clearer separation of concerns (creation vs verification) - Better aligns with Terraform best practices ### Current Workaround Users must toggle `is_verified` from `false` to `true` in a second apply after DNS propagation.
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/oneuptime#151