@@ -158,7 +158,7 @@ Because your database is managed by Vercel, you can only perform these actions *
- Monitor usage via **Storage → Usage** (also available in Neon Console)
- Create additional databases (each becomes a new Neon project)
- Rename or delete a database (deleting removes the underlying Neon project permanently)
-- Manage members / collaborators (handled through Vercel "Members", not the Neon Console) - (see [FAQ](#frequently-asked-questions-faq) for details)
+- Manage members / collaborators (handled through Vercel "Members", not the Neon Console) - (see [FAQ](#frequently-asked-questions) for details)
- Delete the Neon organization (only happens automatically if you uninstall the integration)
- Update connection-string environment variables (prefix changes, etc.)
@@ -255,16 +255,20 @@ Branches you don't delete are eventually [archived](/docs/guides/branch-archivin
- Cannot install if you currently use Vercel Postgres (deprecated) - contact Vercel about transitioning
- **Preview deployment environment variables**: Branch-specific connection variables cannot be accessed or viewed in your Vercel project's environment variable settings (they're injected at deployment time only and not stored to avoid manual cleanup when branches are deleted)
-## Frequently Asked Questions (FAQ)
+## Frequently asked questions
-### Why can't I see Vercel team members in the Neon Console?
+
+
+
Users added to your Vercel team aren't automatically visible in the Neon organization. Team members only appear in Neon when they:
1. Click the **Open in Neon** button from the Vercel integration page
2. Complete the authentication flow
-### Why do Vercel team members with 'Member' role have the 'Admin' role in Neon?
+
+
+
This occurs due to how Vercel's JWT tokens map roles to the integration. According to [Vercel's documentation](https://vercel.com/docs/integrations/create-integration/marketplace-api#user-authentication), the JWT token's `user_role` claim doesn't directly map Vercel team roles:
@@ -273,4 +277,8 @@ This occurs due to how Vercel's JWT tokens map roles to the integration. Accordi
As a result, most active Vercel team members receive Admin access in the Neon organization. This is expected behavior and ensures team members can fully manage database resources.
+
+
+
+
diff --git a/content/docs/import/azure-regions-deprecation.md b/content/docs/import/azure-regions-deprecation.md
index 7165eafa590..aeb5635b841 100644
--- a/content/docs/import/azure-regions-deprecation.md
+++ b/content/docs/import/azure-regions-deprecation.md
@@ -56,11 +56,15 @@ If none of these fit, [export your data in Postgres-compatible form](/docs/guide
## Frequently asked questions
-### Why are these regions being deprecated?
+
+
+
We're focusing our infrastructure investment where our customers want to run Neon. Most Neon projects run in AWS regions, so concentrating there lets us ship features and reliability improvements faster, rather than splitting effort to maintain Azure in parallel. For teams that need Azure, [Databricks Lakebase](/docs/guides/migrate-neon-to-lakebase) runs the same Postgres technology as Neon and supports Azure regions.
-### How do I find out which region a project is in?
+
+
+
You can check from the Console, the CLI, or the API:
@@ -70,7 +74,9 @@ You can check from the Console, the CLI, or the API:
-### Which AWS region should I migrate to?
+
+
+
To keep latency similar, choose the AWS region closest to your current Azure region. For the deprecated Azure regions, the nearest AWS equivalents are:
@@ -82,16 +88,26 @@ To keep latency similar, choose the AWS region closest to your current Azure reg
If your workload has specific latency or data residency requirements, pick the region closest to your users.
-### What changes about my project when I migrate to a new region?
+
+
+
A region migration creates a **new** Neon project in the target region. The new project gets a new hostname, so you'll need to update connection strings in your application. The new project also has a different project ID. Project-level settings (branches, integrations, autoscaling, IP Allow rules, monitoring) are configured per project. See the [migration guide](/docs/import/migrate-neon-to-another-region) for method-specific steps.
-### Should I take a backup before migrating?
+
+
+
If your migration method uses `pg_dump` and `pg_restore`, the dump itself is a backup. If you're using Postgres logical replication, it's good practice to take a `pg_dump` snapshot of your source database first. See [Backups](/docs/manage/backups).
-### How do I contact Neon about my Azure projects?
+
+
+
Keep an eye on your inbox for communication from us. If you have specific constraints, such as regulatory requirements or migration dependencies, reply to any migration outreach you receive or contact [Neon Support](https://console.neon.tech/app/projects?modal=support).
+
+
+
+
diff --git a/content/docs/introduction/plans.md b/content/docs/introduction/plans.md
index ddff9ccf331..4e8f0032860 100644
--- a/content/docs/introduction/plans.md
+++ b/content/docs/introduction/plans.md
@@ -22,7 +22,7 @@ redirectFrom:
- /docs/reference/billing-sample
- /docs/introduction/legacy-plans
- /docs/introduction/extra-usage
-updatedOn: '2026-08-26T18:49:52.579Z'
+updatedOn: '2026-08-26T05:16:28.993Z'
---
Neon offers plans to support you at every stage, from your first prototype to production at scale.
@@ -529,94 +529,116 @@ The following examples show what your monthly bill might look like on the **Laun
**Amount due:** **$658.70**
-## FAQs
-
-
-
-What is a CU?
-: A CU (Compute Unit) is Neon's measure of compute size. Each CU allocates approximately 4 GB of RAM to the database instance, along with associated CPU and local SSD resources. Scaling up increases these resources linearly. For example, a 2 CU compute has 8 GB RAM.
-
-How is compute usage measured in Neon?
-: Compute usage is measured in **CU-hours**:
- CU-hours = compute size (in CU) × hours running
- Examples:
- • 0.25 CU for 4 hours = 1 CU-hour
- • 2 CU for 3 hours = 6 CU-hours
- Your plan's compute price per CU-hour depends on whether you are on Launch or Scale. On the Free plan, you have 100 CU-hours/month included.
-
-How is storage usage billed in Neon?
-: Storage is billed based on actual usage, measured in **GB-months**:
- 1 GB-month = 1 GB stored for 1 month
- Storage usage is metered hourly and summed over the month. For child branches, you're billed for the minimum of accumulated changes or logical data size; capped at your actual data size. On the Free plan, you get 0.5 GB per project.
-
-How do branches affect storage?
-: Your root branch contains your main data. Child branches share data with the root until changes are made. Child branches are billed for the minimum of accumulated changes or logical data size; you never pay more than your actual data size. Delete unused branches to control storage costs.
-
-How is extra branch usage billed?
-: Paid plans include a set number of branches per project. Additional branches are billed at **$1.50/branch-month**, prorated hourly (about $0.002/hour).
- Example: If your plan includes 10 branches and you run 2 extra branches for 5 hours each, that's 10 branch-hours (~$0.02).
-
-How are instant restores billed?
-: Neon charges for PITR (point-in-time restore) storage only for branches you can point-in-time restore from: root branches. The charge is based on the amount of change history retained on those branches, not the number of restores you perform. Child branches do not add to PITR storage charges.
- • Free: Up to 6 hours of history, capped at 1 GB of changes, no charge.
- • Launch: Up to 7 days of history, billed at $0.20/GB-month.
- • Scale: Up to 30 days of history, billed at $0.20/GB-month.
- Change history is stored as Postgres WAL records.
-
-Is instant restore history accumulated at the project or branch level?
-: You can only point-in-time restore from root branches, so only root branches contribute to your billed PITR storage. You set a single **history window** (for example, 7 days or 30 days) for the entire project for **instant restore**. You cannot enable, disable, or configure the history window per branch.
-
-Can I disable scale-to-zero?
-: Free: No, it's always enabled (5 min idle timeout).
- Launch: Yes, you can disable it.
- Scale: Yes, fully configurable (1 minute to always-on). Learn more: [Scale to zero](/docs/introduction/scale-to-zero)
-
-What is autoscaling and how does it work?
-: Autoscaling adjusts compute size based on load, between your set min/max limits. All plans support it, but maximum CU differs: Free up to 2 CU, Launch and Scale up to 16 CU. Scale supports up to 56 CU for fixed-size computes. Learn more: [Autoscaling](/docs/introduction/autoscaling)
-
-How are read replicas billed?
-: Each read replica is its own compute and contributes to CU-hours.
-
-Do public network transfer limits reset each month?
-: Yes. Free includes 5 GB/month. Launch and Scale include 500 GB per project per month. Beyond that, it's $0.10/GB.
-
-How is private network transfer billed?
-: Only available on Scale: $0.01/GB, bidirectional, between Neon and private network services.
-
-What are the limits and quotas for the Free plan?
-: The Free plan costs $0/month and includes 100 projects, 10 branches per project, 100 CU-hours of compute per project per month, autoscaling up to 2 CU (≈8 GB RAM), 0.5 GB of storage per project, and 5 GB of public network transfer per month. It also includes a 6-hour instant restore history (capped at 1 GB-month of changes), 1 manual snapshot, up to 60,000 Managed Better Auth MAU, 1 day of monitoring history, and community support. Scale to zero is always enabled (computes suspend after 5 minutes of inactivity) and can't be disabled. Compute (CU-hours) and network transfer reset each monthly billing period; projects, branches, and storage are continuous limits. For the full row-by-row breakdown, see the [Plan overview](#plan-overview) table.
-
-What happens if I exceed my Free plan limits?
-: On the Free plan, when you run out of CU-hours or public network transfer, your compute is suspended until the next billing period or until you upgrade. Exceeding the 0.5 GB storage cap causes operations that increase storage (inserts, updates, and deletes) to fail until you free space or upgrade. Branch creation fails once you reach 10 branches per project. None of these limits delete your data.
-
-Do you charge for idle computes?
-: If scale-to-zero is enabled, no. Computes that are suspended do not accrue CU-hours.
-
-What is the difference between root and child branch storage billing?
-: Root branches are billed for their full logical data size. Child branches are billed for the minimum of accumulated changes since creation or logical data size; ensuring you never pay more than your actual data size.
-
-Can I get more than the listed project limit?
-: Yes, on Scale you can request increases for projects beyond the listed limit.
-
-Why is the compute rate higher on Scale than Launch?
-: Scale includes higher availability, advanced security features, compliance certifications, and SLAs. The higher CU-hour rate reflects these additional capabilities.
-
-How can I control my costs?
-: • Set a maximum autoscaling limit to cap compute size.
- • Enable scale-to-zero for idle databases.
- • Delete unused branches to reduce storage costs.
- • Shorten your **history window** to reduce **History** usage (instant restore storage).
- For more detailed strategies, see our [Cost optimization](/docs/introduction/cost-optimization) guide.
-
-Do you offer credits for startups?
-: Yes, venture-backed startups may apply for the Neon Startup Program. Learn more: [Startup Program](/startup)
-
-How is storage charged for snapshots?
-: Snapshot storage is billed at $0.09/GB-month.
-
-Is storage cost different for archived branches?
-: No. Archived branches are billed at the same rate as active branches. Neon automatically archives inactive branches to optimize storage resources and maintain a cost-efficient storage infrastructure. See [Branch archiving](/docs/guides/branch-archiving) for details on how archiving works.
-
-
+## Frequently asked questions
+
+
+
+
+A CU (Compute Unit) is Neon's measure of compute size. Each CU allocates approximately 4 GB of RAM to the database instance, along with associated CPU and local SSD resources. Scaling up increases these resources linearly. For example, a 2 CU compute has 8 GB RAM.
+
+
+
+Compute usage is measured in **CU-hours**:
+CU-hours = compute size (in CU) × hours running
+Examples:
+• 0.25 CU for 4 hours = 1 CU-hour
+• 2 CU for 3 hours = 6 CU-hours
+Your plan's compute price per CU-hour depends on whether you are on Launch or Scale. On the Free plan, you have 100 CU-hours/month included.
+
+
+
+Storage is billed based on actual usage, measured in **GB-months**:
+1 GB-month = 1 GB stored for 1 month
+Storage usage is metered hourly and summed over the month. For child branches, you're billed for the minimum of accumulated changes or logical data size; capped at your actual data size. On the Free plan, you get 0.5 GB per project.
+
+
+
+Your root branch contains your main data. Child branches share data with the root until changes are made. Child branches are billed for the minimum of accumulated changes or logical data size; you never pay more than your actual data size. Delete unused branches to control storage costs.
+
+
+
+Paid plans include a set number of branches per project. Additional branches are billed at **$1.50/branch-month**, prorated hourly (about $0.002/hour).
+Example: If your plan includes 10 branches and you run 2 extra branches for 5 hours each, that's 10 branch-hours (~$0.02).
+
+
+
+Neon charges for PITR (point-in-time restore) storage only for branches you can point-in-time restore from: root branches. The charge is based on the amount of change history retained on those branches, not the number of restores you perform. Child branches do not add to PITR storage charges.
+• Free: Up to 6 hours of history, capped at 1 GB of changes, no charge.
+• Launch: Up to 7 days of history, billed at $0.20/GB-month.
+• Scale: Up to 30 days of history, billed at $0.20/GB-month.
+Change history is stored as Postgres WAL records.
+
+
+
+You can only point-in-time restore from root branches, so only root branches contribute to your billed PITR storage. You set a single **history window** (for example, 7 days or 30 days) for the entire project for **instant restore**. You cannot enable, disable, or configure the history window per branch.
+
+
+
+Free: No, it's always enabled (5 min idle timeout).
+Launch: Yes, you can disable it.
+Scale: Yes, fully configurable (1 minute to always-on). Learn more: [Scale to zero](/docs/introduction/scale-to-zero)
+
+
+
+Autoscaling adjusts compute size based on load, between your set min/max limits. All plans support it, but maximum CU differs: Free up to 2 CU, Launch and Scale up to 16 CU. Scale supports up to 56 CU for fixed-size computes. Learn more: [Autoscaling](/docs/introduction/autoscaling)
+
+
+
+Each read replica is its own compute and contributes to CU-hours.
+
+
+
+Yes. Free includes 5 GB/month. Launch and Scale include 500 GB per project per month. Beyond that, it's $0.10/GB.
+
+
+
+Only available on Scale: $0.01/GB, bidirectional, between Neon and private network services.
+
+
+
+The Free plan costs $0/month and includes 100 projects, 10 branches per project, 100 CU-hours of compute per project per month, autoscaling up to 2 CU (≈8 GB RAM), 0.5 GB of storage per project, and 5 GB of public network transfer per month. It also includes a 6-hour instant restore history (capped at 1 GB-month of changes), 1 manual snapshot, up to 60,000 Managed Better Auth MAU, 1 day of monitoring history, and community support. Scale to zero is always enabled (computes suspend after 5 minutes of inactivity) and can't be disabled. Compute (CU-hours) and network transfer reset each monthly billing period; projects, branches, and storage are continuous limits. For the full row-by-row breakdown, see the [Plan overview](#plan-overview) table.
+
+
+
+On the Free plan, when you run out of CU-hours or public network transfer, your compute is suspended until the next billing period or until you upgrade. Exceeding the 0.5 GB storage cap causes operations that increase storage (inserts, updates, and deletes) to fail until you free space or upgrade. Branch creation fails once you reach 10 branches per project. None of these limits delete your data.
+
+
+
+If scale-to-zero is enabled, no. Computes that are suspended do not accrue CU-hours.
+
+
+
+Root branches are billed for their full logical data size. Child branches are billed for the minimum of accumulated changes since creation or logical data size; ensuring you never pay more than your actual data size.
+
+
+
+Yes, on Scale you can request increases for projects beyond the listed limit.
+
+
+
+Scale includes higher availability, advanced security features, compliance certifications, and SLAs. The higher CU-hour rate reflects these additional capabilities.
+
+
+
+• Set a maximum autoscaling limit to cap compute size.
+• Enable scale-to-zero for idle databases.
+• Delete unused branches to reduce storage costs.
+• Shorten your **history window** to reduce **History** usage (instant restore storage).
+For more detailed strategies, see our [Cost optimization](/docs/introduction/cost-optimization) guide.
+
+
+
+Yes, venture-backed startups may apply for the Neon Startup Program. Learn more: [Startup Program](/startup)
+
+
+
+Snapshot storage is billed at $0.09/GB-month.
+
+
+
+No. Archived branches are billed at the same rate as active branches. Neon automatically archives inactive branches to optimize storage resources and maintain a cost-efficient storage infrastructure. See [Branch archiving](/docs/guides/branch-archiving) for details on how archiving works.
+
+
+
diff --git a/content/docs/security/hipaa.md b/content/docs/security/hipaa.md
index bd66bca69bc..f20bd7ca0aa 100644
--- a/content/docs/security/hipaa.md
+++ b/content/docs/security/hipaa.md
@@ -7,7 +7,7 @@ summary: >-
CLI. Enabling HIPAA on a project is irreversible and triggers a compute
restart. Breach notifications are issued within five business days.
enableTableOfContents: true
-updatedOn: '2026-07-15T00:08:00.682Z'
+updatedOn: '2026-08-26T05:16:28.993Z'
---
Neon offers HIPAA compliance as a self-serve feature available to customers on the [Scale](/docs/introduction/plans) plan.
@@ -373,16 +373,23 @@ For step-by-step instructions, see [Delete a project](/docs/manage/projects#dele
If you want to disable HIPAA for your Neon organization entirely, you need to [submit a support request](https://console.neon.tech/app/projects?modal=support). This can only be done after all HIPAA-enabled projects have been deleted.
-## Frequently Asked Questions
+## Frequently asked questions
-**Q: Can I request Neon to delete my PHI?**
-A: Yes, upon termination of services, we will securely delete or return your PHI.
+
-**Q: How does Neon ensure compliance with HIPAA?**
-A: We conduct regular internal audits and provide training to our employees to ensure adherence to HIPAA requirements.
+
+Yes, upon termination of services, we will securely delete or return your PHI.
+
-**Q: What should I do if I suspect a data breach?**
-A: Contact our security team immediately at security@neon.tech.
+
+We conduct regular internal audits and provide training to our employees to ensure adherence to HIPAA requirements.
+
+
+
+Contact our security team immediately at security@neon.tech.
+
+
+
## Contact information
diff --git a/src/components/pages/doc/faq/faq-item.jsx b/src/components/pages/doc/faq/faq-item.jsx
new file mode 100644
index 00000000000..dc7240b66f5
--- /dev/null
+++ b/src/components/pages/doc/faq/faq-item.jsx
@@ -0,0 +1,46 @@
+import PropTypes from 'prop-types';
+import slugify from 'slugify';
+
+import { cn } from 'utils/cn';
+
+const FaqItem = ({ question, children, id = null, defaultOpen = false }) => {
+ const itemId =
+ id ||
+ slugify(question, {
+ lower: true,
+ strict: true,
+ remove: /[*+~.()'"!:@?]/g,
+ }).replace(/_/g, '');
+
+ return (
+
+
+
+
+ {question}
+
+
+ {children}
+
+ );
+};
+
+FaqItem.propTypes = {
+ question: PropTypes.string.isRequired,
+ children: PropTypes.node.isRequired,
+ id: PropTypes.string,
+ defaultOpen: PropTypes.bool,
+};
+
+export default FaqItem;
diff --git a/src/components/pages/doc/faq/faq.jsx b/src/components/pages/doc/faq/faq.jsx
new file mode 100644
index 00000000000..2b02e224ebe
--- /dev/null
+++ b/src/components/pages/doc/faq/faq.jsx
@@ -0,0 +1,74 @@
+import PropTypes from 'prop-types';
+import { Children } from 'react';
+import slugify from 'slugify';
+
+import JsonLd from 'components/shared/json-ld';
+import { cn } from 'utils/cn';
+
+// Block-level tags whose content should be separated by whitespace when we
+// flatten JSX children into the plain-text answer used for FAQPage JSON-LD.
+const BLOCK_TAGS = new Set([
+ 'p',
+ 'li',
+ 'ul',
+ 'ol',
+ 'div',
+ 'br',
+ 'pre',
+ 'blockquote',
+ 'h1',
+ 'h2',
+ 'h3',
+ 'h4',
+ 'h5',
+ 'h6',
+]);
+
+// Recursively extract readable text from arbitrary MDX/JSX children so the
+// structured-data answer stays in sync with what the reader sees.
+const extractText = (node) => {
+ if (node === null || node === undefined || typeof node === 'boolean') return '';
+ if (typeof node === 'string' || typeof node === 'number') return String(node);
+ if (Array.isArray(node)) return node.map(extractText).join('');
+ if (node.props) {
+ const inner = extractText(node.props.children);
+ return BLOCK_TAGS.has(node.type) ? `${inner} ` : inner;
+ }
+ return '';
+};
+
+const Faq = ({ children, className = null }) => {
+ const items = Children.toArray(children).filter((child) => child?.props?.question);
+
+ const faqSchema = {
+ '@context': 'https://schema.org',
+ '@type': 'FAQPage',
+ mainEntity: items.map((item) => ({
+ '@type': 'Question',
+ name: item.props.question,
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: extractText(item.props.children).replace(/\s+/g, ' ').trim(),
+ },
+ })),
+ };
+
+ // Unique id keeps next/script from deduplicating multiple FAQ blocks on one page.
+ const scriptId = items.length
+ ? `faq-json-ld-${slugify(items[0].props.question, { lower: true, strict: true })}`
+ : 'faq-json-ld';
+
+ return (
+
+ {items.length > 0 && }
+ {children}
+
+ );
+};
+
+Faq.propTypes = {
+ children: PropTypes.node.isRequired,
+ className: PropTypes.string,
+};
+
+export default Faq;
diff --git a/src/components/pages/doc/faq/index.js b/src/components/pages/doc/faq/index.js
new file mode 100644
index 00000000000..664c2ab466d
--- /dev/null
+++ b/src/components/pages/doc/faq/index.js
@@ -0,0 +1,5 @@
+import Faq from './faq';
+import FaqItem from './faq-item';
+
+export { FaqItem };
+export default Faq;
diff --git a/src/components/shared/content/content.jsx b/src/components/shared/content/content.jsx
index 43d05b2a8fd..1d7b3bb954e 100644
--- a/src/components/shared/content/content.jsx
+++ b/src/components/shared/content/content.jsx
@@ -26,6 +26,7 @@ import DefinitionList from 'components/pages/doc/definition-list';
import DetailIconCards from 'components/pages/doc/detail-icon-cards';
import DocsLink from 'components/pages/doc/docs-link';
import DocsList from 'components/pages/doc/docs-list';
+import Faq, { FaqItem } from 'components/pages/doc/faq';
import IncludeBlock from 'components/pages/doc/include-block';
import InfoBlock from 'components/pages/doc/info-block';
import LinkPreview from 'components/pages/doc/link-preview';
@@ -199,6 +200,8 @@ const getComponents = (withoutAnchorHeading, isReleaseNote, isPostgres, isTempla
Callout,
CodeTabs,
DetailIconCards,
+ Faq,
+ FaqItem,
TechCards,
CompactCards,
Tag,
diff --git a/src/scripts/process-md-for-llms.js b/src/scripts/process-md-for-llms.js
index 1de64e50f32..1170436e1a6 100644
--- a/src/scripts/process-md-for-llms.js
+++ b/src/scripts/process-md-for-llms.js
@@ -964,6 +964,30 @@ const componentHandlers = {
return node.children || null;
},
+ /**
+ * Faq -> container for FaqItem entries, extract children
+ * answer
+ */
+ Faq(node) {
+ return node.children || null;
+ },
+
+ /**
+ * FaqItem -> heading (question) + answer content
+ * A branch is a copy-on-write clone.
+ */
+ FaqItem(node) {
+ const question = getAttr(node, 'question') || '';
+ const result = [];
+ if (question) {
+ result.push({ type: 'heading', depth: 3, children: [{ type: 'text', value: question }] });
+ }
+ if (node.children?.length > 0) {
+ result.push(...node.children);
+ }
+ return result.length > 0 ? result : null;
+ },
+
/**
* Shared content components with props - load from template files with interpolation
*/
diff --git a/src/styles/doc-content.css b/src/styles/doc-content.css
index 0f68500b756..a23c888c768 100644
--- a/src/styles/doc-content.css
+++ b/src/styles/doc-content.css
@@ -447,16 +447,17 @@
}
}
- /* Details/Summary dropdown styling */
- h2 + details {
+ /* Details/Summary dropdown styling. The Faq component (details.faq-item)
+ opts out of these shared styles and defines its own accordion look. */
+ h2 + details:not(.faq-item) {
@apply mt-6;
}
- details {
+ details:not(.faq-item) {
@apply relative -mb-px border border-gray-new-80 bg-transparent p-4 dark:border-gray-new-20;
}
- details summary {
+ details:not(.faq-item) summary {
@apply flex cursor-pointer items-center gap-2 text-base leading-normal font-normal tracking-tight text-black-pure dark:text-white;
list-style: none;
@@ -468,28 +469,28 @@
}
}
- details[open] > summary::before {
+ details:not(.faq-item)[open] > summary::before {
transform: rotate(90deg);
}
- details > *:not(summary):not(.code-block) {
+ details:not(.faq-item) > *:not(summary):not(.code-block) {
@apply mt-6 pl-[26px] text-base leading-normal font-normal tracking-tight text-gray-new-30 dark:text-gray-new-85;
}
- details > * {
+ details:not(.faq-item) > * {
@apply prose-li:text-base prose-li:leading-snug prose-li:tracking-extra-tight;
}
- details > .code-block {
+ details:not(.faq-item) > .code-block {
@apply my-6 ml-[26px];
}
/* Ensure list items inside details have proper spacing */
- details ul {
+ details:not(.faq-item) ul {
@apply mb-0;
}
- details ul > li:last-child {
+ details:not(.faq-item) ul > li:last-child {
@apply mb-0;
}