{"id":1952,"date":"2026-05-09T16:10:22","date_gmt":"2026-05-09T14:10:22","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/ottimizzare-risorse-plesk-ai-workloads-container-resource-limits-cost-attribution\/"},"modified":"2026-05-09T16:10:22","modified_gmt":"2026-05-09T14:10:22","slug":"ottimizzare-risorse-plesk-ai-workloads-container-resource-limits-cost-attribution","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/ottimizzare-risorse-plesk-ai-workloads-container-resource-limits-cost-attribution\/","title":{"rendered":"Come Ottimizzare Risorse Plesk per AI Workloads: La Mia Procedura Container AI-Native, Resource Limits Dinamici e Cost Attribution su VPS Condiviso"},"content":{"rendered":"<p>Nel 2026, hostare <strong>carichi di lavoro AI su VPS condiviso<\/strong> con Plesk rappresenta una sfida tecnica sempre pi\u00f9 frequente. Ho iniziato a ricevere richieste da clienti che volevano eseguire <em>inference di modelli language model<\/em>, training di <em>machine learning classici<\/em> e preprocessing dati direttamente su infrastrutture multitenancy. Il problema? <strong>Senza limiti di risorse dinamici<\/strong>, un singolo container AI poteva prosciugare RAM e CPU, causando instabilit\u00e0 in tutti gli altri domini.<\/p>\n<p>In questo articolo vi mostro come ho risolto questo scenario negli ultimi mesi: configurazione di container AI-native in Plesk, implementazione di <strong>resource limits granulari tramite cgroups<\/strong>, e soprattutto, come attribuire accuratamente i costi per ogni workload AI in ambienti multi-tenant. Ho testato questa procedura su VPS Hetzner e Vultr da 8-16 vCore con risultati solidi.<\/p>\n<h2>Perch\u00e9 i Workload AI Richiedono una Gestione Risorse Diversa<\/h2>\n<p>La maggior parte dei siti WordPress tradizionali richiede risorse stabili e prevedibili. Ma <strong>un training di modello scikit-learn, un&#8217;inferenza LLM o un preprocessing batch<\/strong> ha pattern di consumo completamente diversi:<\/p>\n<ul>\n<li><strong>Picchi di CPU e RAM improvvisi:<\/strong> durante il training di un albero decisionale XGBoost o forward pass di una rete neurale, l&#8217;utilizzo pu\u00f2 salire dal 10% al 85% in pochi secondi<\/li>\n<li><strong>Consumi di I\/O disco persistenti:<\/strong> <em>machine learning<\/em> legge dataset interi ripetutamente; senza throttling, il disco NVMe satura<\/li>\n<li><strong>Memoria volatile instabile:<\/strong> modelli large language model durante l&#8217;inferenza consumano gigabyte di RAM; poca memoria disponibile = crash OOM<\/li>\n<li><strong>Difficolt\u00e0 di accounting:<\/strong> in Plesk standard, non riesco a tracciare quanto un container AI costa davvero rispetto a un altro subscriber<\/li>\n<\/ul>\n<p>Per questo motivo, <a href=\"https:\/\/darioiannascoli.it\/blog\/cost-management-plesk-obsidian-2026-ottimizzazione-vps-downsizing-roi\/\">la gestione dei costi Plesk nel 2026<\/a> diventa cruciale: se non isolo le risorse, rischio di perdere marginalit\u00e0 o di offrire piani carenti.<\/p>\n<h2>Architettura: Container AI-Native con Plesk Obsidian 18.0.76+<\/h2>\n<p>Nel mio lab ho implementato questa configurazione:<\/p>\n<ul>\n<li><strong>Host principale:<\/strong> Plesk Obsidian 18.0.76+ su AlmaLinux 9 \/ Ubuntu 22.04 (systemd obbligatorio)<\/li>\n<li><strong>Container runtime:<\/strong> Docker CE integrato in Plesk (tramite estensione Docker)<\/li>\n<li><strong>Isolamento risorse:<\/strong> <em>cgroups v2<\/em> di Linux (Resource Controller di Plesk)<\/li>\n<li><strong>Modelli AI:<\/strong> Ollama per <em>inference locale<\/em>, o SDK Python (PyTorch, scikit-learn) per training<\/li>\n<li><strong>Monitoraggio:<\/strong> Plesk Monitoring + custom Prometheus per metriche granulari<\/li>\n<\/ul>\n<p>Ho scelto Docker anzich\u00e9 KVM perch\u00e9 i container sono pi\u00f9 leggeri, e su un VPS 8 vCore con 16GB RAM, ogni megabyte conta.<\/p>\n<h2>Step 1: Abilitare il Resource Controller in Plesk<\/h2>\n<p>Per prima cosa, il Resource Controller di Plesk usa <strong>cgroups<\/strong> (control groups di Linux). <cite>Plesk Cgroups Manager conta il consumo medio di risorse ogni 5 minuti<\/cite>, non in tempo reale. Questo \u00e8 il primo compromesso che devo accettare.<\/p>\n<p><strong>Procedura di abilitazione:<\/strong><\/p>\n<ol>\n<li>Accedo a <strong>Plesk &gt; Tools &amp; Settings &gt; Services Management<\/strong><\/li>\n<li>Cerco &#8220;Resource Controller&#8221; nella lista<\/li>\n<li>Clicco su &#8220;Start&#8221; (deve essere su AlmaLinux\/CentOS 7+ o Ubuntu 16.04+; CloudLinux preferibile)<\/li>\n<li>Verifico che il servizio sia &#8220;Running&#8221;: <code>systemctl status pam_cgroup<\/code><\/li>\n<\/ol>\n<p>Comando per validare che cgroups sia attivo:<\/p>\n<pre>cat \/proc\/filesystems | grep cgroup\nls \/sys\/fs\/cgroup\/<\/pre>\n<p>Se ottengo output, sono a posto. Se no, devo aggiornare il kernel o cambiare OS.<\/p>\n<h2>Step 2: Configurare Service Plan con Limiti Dinamici per AI<\/h2>\n<p>In Plesk, un <strong>Service Plan&lt;\/strong definisce i limiti massimi per ciascun subscriber. Per un workload AI, non posso usare i limiti standard da hosting web.<\/p>\n<p><strong>Mio template per un &#8220;AI Model Training Plan&#8221;:&#8221;<\/strong><\/p>\n<ul>\n<li><strong>CPU:<\/strong> 2 core (200% in notazione Plesk) \u2014 sufficiente per training small-to-medium su classical ML<\/li>\n<li><strong>RAM:<\/strong> 4GB \u2014 buffer per caricamento dataset + memoria di sistema<\/li>\n<li><strong>Disk I\/O:<\/strong> 100 IOPS write, 300 IOPS read (NVMe pu\u00f2 fare di pi\u00f9, ma preservo altri subscriber)<\/li>\n<li><strong>Disk Space:<\/strong> 100GB (per dataset + modelli salvati)<\/li>\n<li><strong>Processes:<\/strong> 200 (Python + worker processes + logging)<\/li>\n<li><strong>File Descriptors:<\/strong> 8192<\/li>\n<\/ul>\n<p>Procedura in Plesk:<\/p>\n<ol>\n<li><strong>Plesk &gt; Service Plans<\/strong><\/li>\n<li>&#8220;Create a Service Plan&#8221; &gt; Name = &#8220;AI Training Basic&#8221;<\/li>\n<li>Navigo a <strong>RAM, CPU, Disk I\/O<\/strong><\/li>\n<li>Configuro i limiti come sopra<\/li>\n<li>Salvo<\/li>\n<\/ol>\n<p>Ho testato inizialmente con limiti pi\u00f9 alti (4 core), ma ho notato che un cliente faceva brute-force di feature engineering e prosciugava tutto. Con 2 core + 4GB, il training \u00e8 pi\u00f9 lento, ma stabile.<\/p>\n<h2>Step 3: Distribuire Container AI con Docker e Limiti di Risorsa<\/h2>\n<p><strong>Non sto hostando l&#8217;AI inside Plesk subscription direttamente<\/strong> \u2014 troppo rischioso. Invece, creo un <strong>container Docker<\/strong> per ogni client AI, legandolo alla subscription Plesk.<\/p>\n<p>Esempio: Ollama (LLM server) con inference di Llama 2:<\/p>\n<pre>docker run -d \n  --name ollama-client-alice \n  --cpus=\"2\" \n  --memory=\"4g\" \n  --memory-swap=\"5g\" \n  --blkio-weight=300 \n  -v \/var\/www\/alice-ai:\/root\/.ollama \n  -p 11434:11434 \n  ollama\/ollama:latest \n  ollama serve<\/pre>\n<p>Spiegazione flags:<\/p>\n<ul>\n<li><code>--cpus=\"2\"<\/code> \u2014 massimo 2 CPU core (come nel Service Plan)<\/li>\n<li><code>--memory=\"4g\"<\/code> \u2014 hard limit 4GB RAM (OOM killer interviene se superato)<\/li>\n<li><code>--memory-swap=\"5g\"<\/code> \u2014 permetto 1GB swap (non ideale per AI, ma fallback utile)<\/li>\n<li><code>--blkio-weight=300<\/code> \u2014 priorizzazione I\/O relativa (default 500)<\/li>\n<li><code>-v \/var\/www\/alice-ai:\/root\/.ollama<\/code> \u2014 bind mount directory cliente, isolata<\/li>\n<\/ul>\n<p>Per training Python + PyTorch con limiti CPU\/GPU:<\/p>\n<pre>docker run -d \n  --name pytorch-training-bob \n  --cpus=\"2.5\" \n  --memory=\"6g\" \n  --gpus='\"device=0\"' \n  -v \/var\/www\/bob-training:\/workspace \n  -e CUDA_VISIBLE_DEVICES=0 \n  pytorch\/pytorch:latest \n  python train.py<\/pre>\n<p>Se il VPS ha una GPU (rara su VPS, ma possibile con Vultr GPU), posso allocarla tramite <code>--gpus<\/code>.<\/p>\n<h2>Step 4: Monitoraggio Granulare e Troubleshooting<\/h2>\n<p>Qui affrontiamo il primo vero problema: <cite>in Plesk c&#8217;\u00e8 spesso un grande divario tra ci\u00f2 che mostra il Monitoring, cosa applica cgroups, e il Process List reale<\/cite>. Ho dovuto sviluppare una procedura di troubleshooting.<\/p>\n<p><strong>Verificare applicazione limiti cgroups real-time:<\/strong><\/p>\n<pre>cat \/sys\/fs\/cgroup\/system.slice\/docker-CONTAINER_ID.scope\/memory.max\ncat \/sys\/fs\/cgroup\/system.slice\/docker-CONTAINER_ID.scope\/cpu.max<\/pre>\n<p><strong>Monitorare container dentro Plesk Obsidian:<\/strong><\/p>\n<ol>\n<li>Vado a <strong>Plesk &gt; Subscriptions &gt; [cliente AI]<\/strong><\/li>\n<li>Navigo a <strong>Resources<\/strong> tab<\/li>\n<li>Vedo utilizzo RAM, CPU, Disk \u2014 ma \u00e8 aggregato e ritardato (5-min average)<\/li>\n<li>Per real-time, lancio da SSH su container: <code>docker stats ollama-client-alice<\/code><\/li>\n<\/ol>\n<p>Ho creato uno script bash di monitoraggio custom per tracciare anomalie:<\/p>\n<pre>#!\/bin\/bash\n# monitor-ai-containers.sh\necho \"=== Container AI Resource Usage ===\"\nfor container in $(docker ps --filter \"label=type=ai\" --format \"{{.Names}}\"); do\n  echo \"Container: $container\"\n  docker inspect $container | jq '.[] | {Memory: .HostConfig.Memory, CpuPeriod: .HostConfig.CpuPeriod, CpuQuota: .HostConfig.CpuQuota}'\n  docker stats $container --no-stream --format \"CPU: {{.CPUPerc}} | MEM: {{.MemUsage}}\"\n  echo \"---\"\ndone<\/pre>\n<p>Quando un cliente si lamenta che il training &#8220;va lento&#8221;, eseguo questo script e capisco se \u00e8 davvero throttled dai limiti oppure se \u00e8 il codice che \u00e8 inefficiente.<\/p>\n<h2>Step 5: Cost Attribution e Billing per Workload AI<\/h2>\n<p>Il punto critico: <strong>come fatturo il cliente AI in modo equo?<\/strong> Non posso semplicemente dirgli &#8220;\u20ac50\/mese per un container&#8221; \u2014 devo mostrare cosa ha consumato realmente.<\/p>\n<p><strong>Approccio FinOps che uso:<\/strong><\/p>\n<ol>\n<li><strong>Compute CPU-hour:<\/strong> traccia ore di utilizzo CPU medio (da cgroups) \u00d7 tariffa \u20ac\/CPU-hour<\/li>\n<li><strong>Memoria peak:<\/strong> RAM massima allocata durante il mese \u00d7 tariffa GB<\/li>\n<li><strong>Storage training:<\/strong> dataset + checkpoints modello \u00d7 GB-month<\/li>\n<li><strong>I\/O operazioni:<\/strong> IOPS consumati (discreto, da cgroups blkio)<\/li>\n<\/ol>\n<p>Implemento questo tramite uno script Python + database SQLite\/PostgreSQL:<\/p>\n<pre># cost_attribution.py\nimport subprocess\nimport json\nfrom datetime import datetime\n\ndef get_container_stats(container_id):\n    cmd = f\"docker stats {container_id} --no-stream --format '{{{{json .}}}}'\"\n    result = subprocess.run(cmd, shell=True, capture_output=True, text=True)\n    return json.loads(result.stdout)\n\ndef calculate_hourly_cost(cpu_percent, memory_bytes, iops):\n    cpu_cost = (float(cpu_percent.rstrip('%')) \/ 100) * 2 * 0.05  # 2 CPU cores @ $0.05\/CPU-hour\n    mem_cost = (memory_bytes \/ (1024**3)) * 0.01  # $0.01\/GB-hour\n    io_cost = iops * 0.0001  # $0.0001 per 100 IOPS\n    return cpu_cost + mem_cost + io_cost\n\n# Logging in database\nfor container in ['ollama-client-alice', 'pytorch-training-bob']:\n    stats = get_container_stats(container)\n    cost = calculate_hourly_cost(stats['CPUPerc'], int(stats['MemUsage'].split('M')[0])*1024*1024, 50)\n    print(f\"{container}: ${cost:.4f} this hour\")<\/pre>\n<p>Ogni ora, uno scheduler (cron o systemd timer) esegue questo script e scrive i dati in una tabella. Al fine mese, genero una fattura dettagliata per ogni cliente AI.<\/p>\n<p><strong>Struttura dati di cost attribution:<\/strong><\/p>\n<ul>\n<li><code>container_id<\/code> \u2014 identificatore unico<\/li>\n<li><code>subscriber_id<\/code> \u2014 ID Plesk del cliente<\/li>\n<li><code>timestamp<\/code> \u2014 quando \u00e8 stato misurato<\/li>\n<li><code>cpu_percent<\/code> \u2014 % CPU medio (da cgroups)<\/li>\n<li><code>memory_mb<\/code> \u2014 memoria usata<\/li>\n<li><code>iops_read<\/code>, <code>iops_write<\/code> \u2014 operazioni disco<\/li>\n<li><code>cost_usd<\/code> \u2014 costo imputato quella ora<\/li>\n<\/ul>\n<h2>Step 6: Throttling Intelligente Quando Risorse Scarseggiano<\/h2>\n<p>Su un VPS da 8 vCore, se due clienti lanciano training contemporaneamente, il server crolla. Ho implementato un <strong>throttling dinamico<\/strong>.<\/p>\n<p>Script di health check e throttling:<\/p>\n<pre>#!\/bin\/bash\n# throttle-ai-containers.sh\nCPU_THRESHOLD=75  # se CPU &gt; 75%, throttle\nMEM_THRESHOLD=80  # se RAM &gt; 80%, throttle\n\nCPU_USAGE=$(top -bn1 | grep \"Cpu(s)\" | awk '{print int($2)}')\nMEM_USAGE=$(free | grep Mem | awk '{printf(\"%.0f\", $3\/$2 * 100.0)}')\n\nif [ $CPU_USAGE -gt $CPU_THRESHOLD ]; then\n  echo \"CPU overloaded ($CPU_USAGE%). Throttling AI containers...\"\n  for container in $(docker ps --filter \"label=type=ai\" --format \"{{.Names}}\"); do\n    # Reduce CPU quota to 1 core temporarily\n    docker update --cpus=\"1\" $container\n  done\nfi\n\nif [ $MEM_USAGE -gt $MEM_THRESHOLD ]; then\n  echo \"Memory overloaded ($MEM_USAGE%). Killing lowest-priority container...\"\n  docker stop $(docker ps --filter \"label=priority=low\" --format \"{{.Names}}\" | head -1)\nfi<\/pre>\n<p>Questo script gira ogni 2 minuti via cron. Se la CPU sale oltre 75%, riduco i core allocati ai container AI da 2 a 1, dandoli priorit\u00e0 a WordPress\/web standard.<\/p>\n<h2>Sfide e Soluzioni Reali che Ho Affrontato<\/h2>\n<p><strong>Problema 1: MySQL\/MariaDB Ottiene Priorit\u00e0 Bassa<\/strong><\/p>\n<p><cite>MySQL\/MariaDB opera come processo singolo, quindi non \u00e8 possibile monitorare il consumo CPU specifico di una subscription nei tool di monitoraggio Plesk<\/cite>. Se un cliente AI fa heavy JOIN con il database, blocca tutti gli altri. Ho risolto con:<\/p>\n<ul>\n<li>Separazione database: database read-only per training, database transazionale per web<\/li>\n<li>Connection pooling: PgBouncer per limitare connessioni\/query concorrenti<\/li>\n<\/ul>\n<p><strong>Problema 2: Cgroups Non Blocca in Real-Time<\/strong><\/p>\n<p><cite>Cgroups non \u00e8 utile per bot aggressivi o picchi improvvisi; bot moderni sopraffanno il server in pochi minuti prima che cgroups rilevino il problema<\/cite>. La soluzione:<\/p>\n<ul>\n<li>Implemento un WAF (ModSecurity in Plesk) per bloccare bot<\/li>\n<li>Rate limiting a livello nginx per subscription<\/li>\n<li>Per AI container, uso timeout stretti (30 secondi per inference) + job queue (Celery)<\/li>\n<\/ul>\n<p><strong>Problema 3: Docker vs Plesk Non Sincronizzano Limiti<\/strong><\/p>\n<p>Se creo un docker container con <code>--memory=\"4g\"<\/code> ma il Service Plan Plesk dice 2GB, chi vince? Docker. Plesk non ha visibilit\u00e0 sui container. Ho risolto con uno script di validazione:<\/p>\n<pre>#!\/bin\/bash\n# validate-limits.sh\nSUBSCRIBER_ID=$1\nSERVICE_PLAN=$(plesk bin subscription --info $SUBSCRIBER_ID | grep -i \"plan\" | awk '{print $2}')\nPLAN_MEMORY=$(plesk bin service_plan --info \"$SERVICE_PLAN\" | grep -i \"memory\" | awk '{print $NF}')\nCONTAINER_ID=$(docker ps -a --filter \"label=subscriber=$SUBSCRIBER_ID\" --format \"{{.ID}}\")\nCONTAINER_MEMORY=$(docker inspect $CONTAINER_ID | jq -r '.[].HostConfig.Memory')\n\nif [ \"$PLAN_MEMORY\" != \"$CONTAINER_MEMORY\" ]; then\n  echo \"WARNING: Mismatch! Plan=$PLAN_MEMORY, Container=$CONTAINER_MEMORY\"\n  docker update --memory=\"${PLAN_MEMORY}b\" $CONTAINER_ID\nfi<\/pre>\n<p>Eseguo questo script ogni notte per sincronizzare.<\/p>\n<h2>FAQ<\/h2>\n<h3>Posso fare training di modelli LLM grandi (7B+ parametri) su un VPS Plesk condiviso?<\/h3>\n<p>Teoricamente s\u00ec, ma \u00e8 rischioso. Un Llama 2 7B richiede ~14GB VRAM solo per inferenza. Su un VPS 32GB con 4-5 subscriber, non ho margine. Consiglio: usa VPS dedicato per training LLM, oppure caching + batch inference. <a href=\"https:\/\/darioiannascoli.it\/blog\/costi-cloud-ai-2026-gpu-scarsita-energia-tariffazione-token-self-hosting-roi\/\">Il costo real dei workload AI nel 2026<\/a> spesso giustifica un server separato.<\/p>\n<h3>Come Plesk Obsidian MCP 2.0 aiuta con AI?<\/h3>\n<p><a href=\"https:\/\/darioiannascoli.it\/blog\/plesk-obsidian-mcp-2-agenti-ia-wordpress-domini-database-setup\/\">Plesk MCP 2.0 permette agenti IA autonomi di gestire domini e database tramite linguaggio naturale<\/a>. Per cost tracking, posso far loggare gli agenti IA tutte le operazioni (creazione container, allocation risorse), ottenendo un audit trail completo per billing.<\/p>\n<h3>Quale framework ML scegliere? PyTorch o TensorFlow?<\/h3>\n<p><strong>PyTorch:<\/strong> pi\u00f9 leggero, ideale per VPS. <strong>TensorFlow:<\/strong> overkill per risorse limitate. Scikit-learn + XGBoost = scelta migliore per classical ML su shared hosting. Se necessario deep learning, Ollama per inference pura (no training).<\/p>\n<h3>Come evitare che un cliente AI rompa il VPS di tutti gli altri?<\/h3>\n<p>Tre strati di difesa: (1) <strong>cgroups limits<\/strong> (CPU, RAM, I\/O), (2) <strong>container isolation<\/strong> (Docker, namespace di rete), (3) <strong>throttling dinamico<\/strong> (script che monitora e riduce risorse se picchi). Se uno fallisce, i altri due frenano i danni.<\/p>\n<h3>Quale provider VPS mi consigli per AI + Plesk?<\/h3>\n<p>Ho testato Hetzner (buon rapporto CPU\/RAM), Vultr (GPU disponibili, prezzati orariamente) e OVHcloud (server locali EU per compliance). Per un VPS 8-16 vCore + AI, budget \u20ac30-60\/mese. Evito provider con SLA di rete deboli (latency &gt;50ms danneggia inference).<\/p>\n<h2>Conclusione: Gestire AI su Plesk VPS Condiviso \u00e8 Possibile<\/h2>\n<p>Nel 2026, molti mi chiedono: &#8220;Posso mettere AI training su Plesk standard?&#8221; La risposta \u00e8 <strong>s\u00ec, ma con disciplina<\/strong>. Ho mostrato come:<\/p>\n<ul>\n<li><strong>Container Docker + cgroups<\/strong> isolano i workload AI<\/li>\n<li><strong>Service Plan dinamici<\/strong> assegnano risorse equamente<\/li>\n<li><strong>Cost attribution scripts<\/strong> tracciabili fatturazione precisa<\/li>\n<li><strong>Throttling intelligente<\/strong> protegge gli altri subscriber<\/li>\n<\/ul>\n<p><strong>Chiave del successo:<\/strong> non fidarsi solo di Plesk \u2014 aggiungere layer di container orchestration (Docker), monitoring custom (Prometheus), e accounting (database SQLite). Plesk rimane l&#8217;interfaccia di gestione, ma il vero controllo sta in scripts e automation.<\/p>\n<p>Se gestite Plesk con clienti AI, comentate qui: quali problemi di resource management affrontate? Avete metodi diversi per cost attribution?<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Come host carichi AI su VPS Plesk condiviso con container Docker isolati, limiti cgroups dinamici e cost attribution accurata per training e inference machine learning nel 2026.<\/p>\n","protected":false},"author":1,"featured_media":1953,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Plesk AI Workloads: Container, Resource Limits, Cost Attribution | 2026","_seopress_titles_desc":"Procedura completa ottimizzazione Plesk per AI: container Docker, cgroups limiti risorse, cost attribution billing, monitoring granulare training ML su VPS condiviso.","_seopress_robots_index":"","footnotes":""},"categories":[4],"tags":[436,733,732,126,116],"class_list":["post-1952","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk","tag-ai-workloads","tag-cost-attribution","tag-docker-containers","tag-machine-learning","tag-plesk"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/1952","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=1952"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/1952\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/1953"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=1952"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=1952"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=1952"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}