@ts-cloud/core 0.9.1 → 0.9.3

package/dist/types.d.ts

@@ -14,7 +14,34 @@ export interface CloudProviderConfig {
      * this project's sites, and adds its own additive rpx `sites.d/<slug>.json`
      * fragment + DNS — never touching the owner's box lifecycle, firewall, or other
      * tenants. The owner provisions and manages the shared box; attachers only
-     * deploy onto it. Requires read access via the same `HCLOUD_TOKEN`.
+     * deploy onto it.
+     *
+     * ## This widens what your CI credential can reach
+     *
+     * Attaching resolves the host by listing the provider's servers with THIS
+     * project's own token, so the owner's box has to be visible to it, which means
+     * both projects live in the same provider project. On Hetzner that is the whole
+     * story: Cloud API tokens are scoped to a project with Read or Read & Write and
+     * offer no per-resource scoping, and a deploy needs write. So the moment this is
+     * set, this project's CI token can modify and delete EVERY server in that
+     * provider project, not just the box it deploys to.
+     *
+     * Concretely, three apps that each owned one box become three pipelines that
+     * each reach all three, plus anything else in the project. That is a real change
+     * in blast radius: a compromised CI run or a mistargeted teardown now reaches
+     * production systems belonging to unrelated apps.
+     *
+     * **Per-project isolation and attaching are mutually exclusive.** An app kept in
+     * its own provider project cannot be attached at all, because its token cannot
+     * see the owner's box. Choosing to co-host is choosing to trade credential
+     * isolation for a shared box; the reverse trade is equally available, and neither
+     * is a default worth stumbling into.
+     *
+     * `describeCredentialReach()` reports what a given token can actually reach, so
+     * the radius can be shown before an attach is approved rather than discovered
+     * afterwards.
+     *
+     * @see https://github.com/stacksjs/ts-cloud/issues/169
      */
     attachTo?: string;
 }
@@ -1660,6 +1687,69 @@ export interface DnsConfig {
      * instead of Route53
      */
     provider?: 'route53' | 'cloudflare' | 'porkbun' | 'godaddy';
+    /**
+     * Records to publish on every deploy, alongside the address records ts-cloud
+     * derives from `sites`.
+     *
+     * This is for the half of a zone a deploy cannot infer — mail (MX, SPF,
+     * DMARC, autodiscover), domain-verification TXT records, third-party CNAMEs.
+     * Those are exactly the records that go missing in a nameserver migration and
+     * are not noticed until someone reports that mail stopped, because nothing in
+     * a normal deploy touches or checks them. Declaring them here makes the zone
+     * reproducible from the repo instead of from someone's memory of a dashboard.
+     *
+     * Reconciliation is **upsert-only**: ts-cloud never deletes a record it was
+     * not asked to manage, because a zone routinely holds records owned by other
+     * tools and people. The one exception is a policy TXT record (SPF, DMARC),
+     * where a *second* record is not additive but a hard failure — see
+     * {@link DnsRecordConfig}.
+     */
+    records?: DnsRecordConfig[];
+}
+/**
+ * One record published by {@link DnsConfig.records}.
+ *
+ * How a record is matched against what already exists depends on its type,
+ * because "the same record" means different things:
+ *
+ *  - **A, AAAA, CNAME** — one value per name in practice, so an existing record
+ *    with this name and type is UPDATED.
+ *  - **MX, SRV, CAA, NS** — legitimately multi-valued, so a record is matched on
+ *    its content and only created when that exact value is absent. Undeclared
+ *    values at the same name are reported, never removed: a stray MX means split
+ *    mail delivery, which the operator must see, but deleting someone else's
+ *    record on a shared zone is worse.
+ *  - **TXT** — multi-valued in general (verification tokens sit beside each
+ *    other), EXCEPT for policy records. Two `v=spf1` records are not two
+ *    policies; they are a permerror, and receivers treat the domain as having no
+ *    usable SPF at all. Two `v=DMARC1` records are likewise ignored wholesale.
+ *    So a TXT whose value opens with a policy tag REPLACES the existing record
+ *    carrying that same tag, and any other TXT at that name is left untouched.
+ */
+export interface DnsRecordConfig {
+    type: 'A' | 'AAAA' | 'CNAME' | 'MX' | 'TXT' | 'SRV' | 'CAA' | 'NS';
+    /**
+     * Record name: `'@'` (or omitted) for the zone apex, a bare label such as
+     * `'autodiscover'`, or a fully-qualified name. Bare labels are qualified with
+     * the zone.
+     */
+    name?: string;
+    /** Record value. */
+    content: string;
+    /** TTL in seconds. @default 3600 */
+    ttl?: number;
+    /** Priority — required for MX, used by SRV. */
+    priority?: number;
+    /**
+     * Cloudflare only: serve through the proxy. @default false
+     *
+     * Declared records default to DNS-only deliberately. Mail records cannot be
+     * proxied at all, and a proxied `autodiscover` CNAME resolves to Cloudflare
+     * rather than Microsoft and quietly breaks client auto-configuration.
+     */
+    proxied?: boolean;
+    /** Free-text note stored with the record where the provider supports it. */
+    comment?: string;
 }
 export interface SecurityConfig {
     waf?: WafConfig;

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@ts-cloud/core",
   "type": "module",
-  "version": "0.9.1",
+  "version": "0.9.3",
   "description": "Core CloudFormation generation library for ts-cloud",
   "author": "Chris Breuer <chris@stacksjs.com>",
   "license": "MIT",
@@ -31,7 +31,7 @@
     "typecheck": "tsc --noEmit"
   },
   "dependencies": {
-    "@ts-cloud/aws-types": "0.9.1"
+    "@ts-cloud/aws-types": "0.9.3"
   },
   "devDependencies": {
     "typescript": "^7.0.2"