5 plugin DeepSeek Harness da installare su un VPS

Quali plugin di DeepSeek Harness vale la pena installare

I plugin di DeepSeek Harness sono codice di terze parti che viene eseguito all'interno dell'agent, con i privilegi dell'agent, su una macchina che paghi. L'elenco della community comprende più di venti categorie e oltre mille voci. Su un server privato virtuale (VPS) a noleggio ne servono cinque: dsh-budget per limitare la spesa, dsh-permission-rules per controllare l'accesso agli strumenti, dsh-defend per rilevare injection e secret, dsh-memory per conservare i dati che devono sopravvivere a una sessione e dsh-web-lan-access solo dopo aver deciso come eseguire l'autenticazione.

Il harness è dsh, l'agent harness open source di DeepSeek, progettato in modo che ogni componente sia un plugin. Il README del progetto lo definisce una developer preview e include l'avvertenza THERE WILL BE COMPATIBILITY-BREAKING CHANGES. Questo aspetto determina ogni scelta descritta di seguito. Blocca la versione dei componenti installati, prevedi che un aggiornamento possa renderli incompatibili e mantieni l'insieme abbastanza ridotto da poterlo esaminare interamente. Se il harness non è ancora in esecuzione, inizia da un'installazione di DeepSeek Harness su un VPS e poi torna qui. Se non sono ancora chiari i componenti in cui questi plugin si integrano, cioè il ciclo dell'agent, i suoi strumenti e la sua memoria, studia prima i concetti fondamentali, perché ogni scelta descritta di seguito è più facile da valutare quando sai quale funzione svolge ogni livello.

Come dsh installa un plugin e dove viene salvata la configurazione

dsh si costruisce a partire dai plugin Cordis, quindi un'istanza in esecuzione è un albero di plugin, non un singolo programma. Un profilo è una composizione denominata di questi plugin. I due template sono web e headless. $DSH_HOME utilizza ~/.dsh come valore predefinito e un profilo si trova in $DSH_HOME/profiles/<name>/. Contiene il proprio package.json, un manifest dsh.profile e un cordis.patch.yml.

dsh plugin --profile web list
dsh plugin --profile web add dsh-budget
dsh plugin --profile web remove dsh-budget

Sono supportati quattro formati sorgente: il nome di un pacchetto npm senza prefisso, un nome con scope come @towzai/dsh-memory, un riferimento GitHub come github:PerryLink/dsh-budget#main e un percorso locale con link: o ./. È preferibile usare il formato GitHub, perché puoi sostituire #main con un commit e ottenere lo stesso codice anche il mese successivo.

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

I livelli vengono applicati in un ordine fisso: ogni bundle nell'ordine elencato nel profilo, quindi il cordis.patch.yml del profilo, il cordis.patch.yml a livello home e infine qualsiasi overlay --patch. L'ordine è importante perché un livello successivo può riconfigurare o rimuovere ciò che è stato impostato da un livello precedente. Se quindi un plugin risulta installato ma non produce alcun effetto, apri il cordis.patch.yml del profilo e verifica due elementi: che il relativo blocco insert sia presente e che nessun livello successivo lo disabiliti.

Al 17 agosto 2026 il pacchetto npm @deepseek-ai/dsh era alla versione 0.1.0-rc.7, mentre i plugin riportati di seguito erano compilati per la linea 0.1.0-rc. dsh-permission-rules e dsh-defend dichiarano la compatibilità con 0.1.0-rc.5 fino a 0.1.0-rc.6, dsh-budget dichiara soltanto 0.1.0-rc.6, dsh-memory imposta solo intervalli peer a partire da ^0.1.0-rc.6 e dsh-web-lan-access non dichiara alcuna versione di dsh. Il 10 ottobre 2026 il tag latest su npm è 0.2.0-rc.2, quindi la differenza è ora maggiore rispetto al momento in cui sono stati scelti questi pin. Questa differenza è normale in questo ecosistema ed è il motivo più comune per cui un plugin smette di caricarsi: l'harness si aggiorna più rapidamente dei plugin che lo circondano. Aggiorna l'harness intenzionalmente, quindi testa un plugin alla volta.

Leggi un plugin prima di considerarlo attendibile

Un plugin dsh non è isolato dal framework. Viene caricato nello stesso albero Cordis e nello stesso processo, con lo stesso utente del sistema operativo, e può accedere alle stesse credenziali del modello e allo stesso albero di lavoro. Installarlo equivale più a eseguire lo script di un'altra persona con sudo che ad aggiungere un'estensione al browser. È la stessa questione di attendibilità sollevata dai plugin di Claude Code, e la risposta è la stessa: leggi il codice oppure non installarlo.

Controlla questi quattro aspetti, in quest'ordine:

• A quali punti di estensione si collega. tools/pre-execute significa che può vedere ogni chiamata agli strumenti e bloccarla. agent/pre-step significa che può vedere i tuoi messaggi. webServer.tapIndex significa che riscrive la pagina servita al browser. Un plugin che non si collega a nessuno di questi punti può fare ben poco; un plugin che si collega a tutti è il tuo confine di sicurezza.
• Se comunica con la rete. Cerca nel codice sorgente fetch, http e qualsiasi nome host scritto direttamente nel codice. Un misuratore dei costi che invia dati al server dello sviluppatore comunica altrove il tuo modello di utilizzo.
• Se legge le credenziali. Qualsiasi componente che accede a credentials.* o a una chiave del provider deve indicare nel README un motivo preciso.
• La licenza e la data dell'ultimo commit. Un plugin senza licenza e non aggiornato da mesi, in un ecosistema che cambia ogni settimana, rappresenta un rischio operativo.

Installa quindi facendo riferimento a un commit anziché a un branch e leggi il blocco di inserimento che l'installer ha scritto in cordis.patch.yml. Quel blocco indica l'ID del plugin e la configurazione registrata; è la descrizione più breve e corretta di ciò che hai appena aggiunto. Tieni le chiavi dei provider fuori dalla portata del plugin, quando il framework lo consente, seguendo un approccio simile a tenere i secret fuori dalla portata degli agenti AI.

dsh-budget: come fermare un agent che spende per tutta la notte?

Un agent su un VPS esegue attività senza supervisione. È proprio questo il motivo per cui lo si installa lì, ma è anche il rischio. dsh-budget misura i token e il costo stimato per modello, sessione e giornata e applica limiti a questi totali.

dsh plugin --profile web add "github:PerryLink/dsh-budget#461d478"

I valori predefiniti sono generosi: 10 USD per sessione, 50 al giorno e 500 al mese. Sono adatti a un team con un budget dedicato. Su un server personale sono abbastanza alti da permettere a un loop senza fine di terminare prima che il limite venga applicato. Per questo è opportuno ridurli già il primo giorno.

[
  {
    "label": "Per session",
    "plugin_default_usd": 10,
    "suggested_start_usd": 2
  },
  {
    "label": "Per day",
    "plugin_default_usd": 50,
    "suggested_start_usd": 5
  },
  {
    "label": "Per month",
    "plugin_default_usd": 500,
    "suggested_start_usd": 40
  }
]

La colonna suggerita è un punto di partenza per un solo operatore su un solo host, non un valore pubblicato. Aumentala quando un mese di utilizzo reale lo giustifica. Un limite mensile di 40 USD con un limite per sessione di 2 interrompe l'attività in modo evidente e tempestivo. È ciò che serve mentre stai ancora valutando il consumo dello strumento.

- id: budget
  config:
    budgets:
      session: 2
      daily: 5
      monthly: 40
    warnRatio: 0.8
    overLimit: block

L'impostazione che modifica il comportamento della macchina è overLimit. Il valore predefinito è alert: visualizza un avviso ma continua a spendere. Per impostazione predefinita, quindi, questo plugin funziona come una dashboard. Impostalo su block e l'harness rifiuta ulteriori chiamate al modello quando viene raggiunto un limite. In questo modo un job notturno si interrompe invece di continuare a generare costi fino al mattino. degrade è la terza modalità: blocca la chiamata e suggerisce un modello più economico indicato nella mappa degradation. È la scelta corretta quando un job deve terminare ma non richiede il modello migliore. warnRatio ha come valore predefinito 0.8, quindi ricevi un avviso all'80 percento del limite.

Esistono due limiti da considerare. Il costo viene calcolato usando una tabella dei prezzi incorporata, integrata con i prezzi forniti dall'utente. Il maintainer avverte che i prezzi incorporati possono cambiare. prices è vuoto per impostazione predefinita. Al commit bloccato 461d478, defaultPrice, il valore di fallback per un modello presente in nessuna delle due tabelle, è 1.0 USD per milione di token di input e 3.0 per milione di token di output. Nella versione corrente di main, verificata il 10 ottobre 2026, il valore predefinito è zero e il modello viene indicato come privo di prezzo. Inserisci i valori reali dei tuoi modelli. In caso contrario, la dashboard è una stima presentata come una misurazione. Il secondo limite riguarda 461d478: il plugin aggrega i dati nel processo in esecuzione a partire dal flusso di eventi della sessione. I totali vengono quindi azzerati quando l'harness viene riavviato. Anche un loop di crash, oppure un supervisor che riavvia dsh, azzera un limite giornaliero. La versione corrente di main salva per impostazione predefinita i bucket giornalieri e mensili (persistence.enabled: true, acquisiti ogni 10 secondi) e li ripristina all'avvio. In questo caso, quindi, un riavvio non annulla più un limite giornaliero o mensile, purché l'harness fornisca il dominio di storage. In sua assenza, l'aggregazione resta locale al processo. main si rivolge inoltre alla linea di harness 0.2. Spostare il commit bloccato significa quindi spostare anche l'harness. In ogni caso, considera dsh-budget una protezione contro i tuoi stessi job e imposta un limite di spesa sull'account del provider come limite effettivo. Questo è l'argomento più ampio illustrato in controllare il costo degli agent AI su un VPS.

Nell'uso quotidiano, utilizza /budget per la panoramica, /budget models per la suddivisione per modello e /budget unblock <scope> per rimuovere un blocco dopo aver deciso di continuare.

dsh-permission-rules: quali chiamate agli strumenti non devono mai essere eseguite?

dsh-permission-rules inserisce regole dichiarative nel flusso tools/pre-execute, quindi una regola viene valutata prima dell'esecuzione di uno strumento. Sono disponibili tre azioni. allow lascia passare la chiamata, deny la blocca e restituisce un motivo leggibile dal modello, mentre ask la inoltra al punto di approvazione ufficiale.

dsh plugin --profile web add "github:PerryLink/dsh-permission-rules#b30b4fb"

Le regole si trovano in .dsh/rules.yaml, relativo alla directory di lavoro della sessione, con un valore globale fallbackPath e un valore opzionale searchUp per risalire verso la root del filesystem. La corrispondenza comprende glob sul nome dello strumento, glob sulle chiavi e sui valori dei parametri, glob sui percorsi relativi al workspace, selettori dell'agente come main o subagent e destinazioni di rete.

rules:
  - match: { tools: [bash], params: { command: "rm -rf*" } }
    action: deny
    reason: "No recursive deletes"
  - match: { tools: [edit, write], paths: ["**/.env*", "**/secrets/**"] }
    action: ask
    reason: "Secret files need confirmation"
  - match: { tools: ["mcp__*"] }
    action: ask
    reason: "MCP tools need confirmation"

La valutazione si interrompe alla prima corrispondenza. Di conseguenza, un allow ampio nelle prime posizioni annulla silenziosamente tutte le regole più specifiche che seguono. Inserire prima i divieti e lasciare per ultime le regole permissive. Il glob del nome dello strumento copre mcp__*. Questo consente di controllare gli strumenti forniti da un server Model Context Protocol (MCP), anziché dal relativo harness, e diventa importante non appena si eseguono server MCP su un VPS.

È necessario pianificare anche un comportamento specifico: ask richiede un soggetto che fornisca una risposta. In un profilo headless potrebbe non esserci nessuno a controllare la sessione. Un ask senza risposta non attende l'arrivo di qualcuno: se non è stato composto alcun risponditore, la catena di approvazione dell'harness chiude per sicurezza e la chiamata viene rifiutata. Su un sistema non presidiato, una regola ask equivale quindi a un deny che non si intendeva impostare. Usare deny per tutto ciò che non si approverebbe mai, mantenere ask per il profilo utilizzato interattivamente e, per consentire le approvazioni in modalità non presidiata, predisporre un percorso di risposta reale. Questo argomento è trattato in controllare le azioni degli agenti AI tramite approvazioni.

dsh-defend: e i prompt injection e i secret esposti?

dsh-defend esegue scansioni in tre punti: i messaggi in ingresso su agent/pre-step, gli argomenti degli strumenti su tools/pre-execute, incluso un controllo contro le eliminazioni distruttive, e i risultati degli strumenti su tools/post-execute. Quest'ultimo punto è particolarmente importante, perché consente di controllare i contenuti recuperati da una pagina web prima che il modello agisca su di essi.

dsh plugin --profile web add "github:PerryLink/dsh-defend#7ba3427"

Le impostazioni predefinite sono prudenti, non rigide: detection.injectionAction, detection.jailbreakAction e detection.secretAction sono tutti ask, mentre detection.secretBlockCritical è true. In questo modo un secret critico viene bloccato indipendentemente dalle altre impostazioni. Su un server non presidiato, imposta su block le azioni che vuoi controllare, perché ask senza nessuno a cui chiedere conferma non è una decisione.

Il design dell'audit è ben concepito. Gli eventi defend/detection registrano l'ID della regola, la famiglia, la categoria, la gravità, la decisione e i dati della scansione, ma non registrano mai il testo corrispondente. I secret vengono registrati solo per tipo. L'abilitazione dell'audit log non crea quindi una seconda copia della credenziale che stavi cercando di proteggere.

È importante chiarire cosa offre questo meccanismo. Il rilevamento si basa su regole e il README dichiara esplicitamente che formulazioni inedite e attacchi articolati in più passaggi possono sfuggire ai controlli. Riduce la frequenza degli attacchi più evidenti. Non rende sicuro indirizzare un agent verso contenuti non attendibili. Mantieni quindi le regole delle autorizzazioni come livello di protezione sottostante.

dsh-memory: cosa ricorda l'agente domani?

Esistono due plugin diversi chiamati dsh-memory. È utile saperlo prima di eseguire un comando di installazione. Installa specificando esplicitamente la sorgente, così otterrai quello descritto qui.

Su un server di piccole dimensioni sceglierei la build SQLite. Si registra come memory, mantiene un unico file in $DSH_HOME/memory/memory.db condiviso tra i profili ed espone memory_write, memory_search e memory_forget. La ricerca usa parole chiave sul testo e sui tag memorizzati. Non richiede un servizio di embedding, una chiave API o un processo aggiuntivo.

dsh plugin --profile web add "github:ben7am1n/dsh-memory#def7c6a"

La configurazione da modificare è ridotta: path indica il file del database, promptRecentCount (valore predefinito 10) specifica quante memorie non fissate vengono incluse e promptMaxChars (valore predefinito 2000) definisce il budget per il rendering. Il plugin si basa su node:sqlite, che in Node 22 e 24 è ancora contrassegnato come sperimentale. Un aggiornamento di Node va quindi verificato, non dato per scontato.

Ecco l'effetto concreto della memoria sulla macchina: le memorie inserite vengono aggiunte al prompt di sistema a ogni turno. promptMaxChars definisce il limite superiore della sezione renderizzata, non una quantità fissa. Tuttavia, quando le memorie archiviate raggiungono quel limite, un budget di 2000 caratteri aggiunge alcune centinaia di token di input a ogni singola richiesta, per sempre. Questo ha un costo reale in fattura. Per questo motivo dsh-budget deve essere installato sul server prima di dsh-memory. Mantieni promptMaxChars contenuto e usa memory_forget per eliminare le memorie non più necessarie, invece di lasciare crescere il file.

La build alternativa salva le memorie in un file YAML ed esegue la ricerca tramite embedding, con inserimento automatico nel prompt. Si installa con dsh plugin --profile web add github:towzai/dsh-memory. La ricerca tramite embedding richiede un'istanza locale di ollama e un modello di embedding, qwen3-embedding:0.6b per impostazione predefinita, modificabile con DSH_MEMORY_EMBED_MODEL. Senza ollama, il plugin passa alla ricerca basata soltanto sulle parole chiave. Il recupero semantico è migliore di quello basato sulle parole chiave. Tuttavia richiede anche un secondo servizio e un insieme di pesi del modello residenti sullo stesso server. In un piano di piccole dimensioni, questa memoria viene sottratta al lavoro per cui hai noleggiato il server. Sceglila quando hai RAM disponibile. Il compromesso generale tra qualità del recupero e costo delle risorse residenti è descritto in memoria locale per gli agenti.

dsh-web-lan-access: l'interfaccia Web deve essere in ascolto oltre il loopback?

npx @deepseek-ai/dsh web espone l'interfaccia su 127.0.0.1:3080. I browser espongono crypto.randomUUID() soltanto in un contesto sicuro, quindi il caricamento della stessa pagina tramite HTTP non cifrato da un altro computer non riesce. dsh-web-lan-access risolve il problema usando webServer.tapIndex per iniettare un piccolo polyfill e modificando il binding del server in 0.0.0.0.

Leggete l'avviso specifico prima di installarlo. Al commit citato qui, e27e909, il README indicava che il binding su 0.0.0.0 rendeva l'agent raggiungibile senza autenticazione da chiunque si trovasse sulla stessa rete locale (LAN) e, su un server con un indirizzo IP pubblico, dall'intera Internet. Solo un breve elenco di metodi sensibili (settings.*, credentials.*, llm.discoverModels) era vincolato al loopback e restituiva 403 per le origini remote. La situazione è cambiata. Le build correnti di harness, verificate il 10 ottobre 2026, autenticando il browser: il launch token contenuto nell'URL stampato viene scambiato con un cookie di sessione firmato, richiesto da ogni route e stream dell'API Host. Il README corrente del plugin definisce trustedHosts un filtro Origin/Host, non un sistema di identificazione, indica che il binding su 0.0.0.0 espone la superficie di autenticazione su ogni interfaccia raggiungibile e ora abilita le impostazioni basate su Host per una pagina remota autenticata. Nelle build correnti, quindi, un browser remoto con sessione autenticata può raggiungere anche le impostazioni Host. Il rischio si è spostato, ma non è scomparso: chiunque possa raggiungere la porta può sondare il login, l'URL stampato è a sua volta una credenziale e, tramite HTTP non cifrato, il token attraversa la rete in chiaro.

Nella maggior parte dei casi questo plugin non serve. Inoltrate invece la porta tramite SSH.

ssh -N -L 3080:127.0.0.1:3080 you@your-server

Aprite quindi http://127.0.0.1:3080 nel browser locale. harness resta in ascolto soltanto sul loopback, quindi nulla viene esposto. Inoltre, poiché i browser considerano 127.0.0.1 un'origine sicura, crypto.randomUUID() è disponibile e non serve alcun polyfill. Un solo comando, nessun plugin e nessuna nuova superficie di attacco.

Installate il plugin soltanto quando un forward non è sufficiente, ad esempio quando un telefono sulla stessa rete deve raggiungere l'interfaccia. In tal caso, eseguite il binding dietro un'interfaccia di rete privata, mantenete una regola firewall che consenta il traffico soltanto da quell'interfaccia e indicate i nomi da usare in trustedHosts della voce web-runtime. Per un accesso realmente multiutente è disponibile dsh-passwords, che aggiunge permessi per subuser, limiti orari sui token per ciascun subuser, quote giornaliere di tempo, certificati TLS automatici (transport layer security) tramite Let's Encrypt e un audit log cifrato. Valutatelo come una piattaforma, non come un plugin: richiede le porte 80 e 443, include un proprio installer e il percorso rapido documentato inoltra uno shell script dalla rete direttamente a bash. Preferite npm install -g dsh-passwords seguito da dsh-passwords install, così il codice resta su disco e potete leggerlo prima dell'esecuzione.

Come rimuovere correttamente un plugin

La disinstallazione richiede due passaggi, ma spesso il secondo viene saltato.

dsh plugin --profile web remove dsh-budget
dsh plugin --profile web list

list non dovrebbe più visualizzarlo. Quindi apri $DSH_HOME/profiles/web/cordis.patch.yml ed elimina eventuali blocchi di inserimento residui che riportano il nome del plugin, perché è questa voce a caricarlo nell'albero. Riavvia l'harness per ricostruire l'albero; un plugin già caricato resta attivo finché non lo fai. Infine, ricorda che i dati restano anche dopo la rimozione del codice. $DSH_HOME/memory/memory.db e .dsh/rules.yaml sopravvivono alla disinstallazione. Eliminali manualmente se l'obiettivo era rimuovere anche i dati.

Cosa ho letto e quando

Ogni riferimento qui indica un commit, non un branch, perché main conterrà codice diverso quando leggerai questo testo. Ho letto tutto il 17 agosto 2026 e, quel giorno, l’harness stesso era alla versione 0.1.0-rc.7 su npm. Ho verificato nuovamente i valori predefiniti e il comportamento descritti sopra confrontandoli con le fonti primarie il 10 ottobre 2026, quando il tag latest su npm era 0.2.0-rc.2.

Verifica nuovamente questi riferimenti prima di copiare un comando. In un ecosistema in anteprima per sviluppatori, un numero di versione associato a una data è l’unico che abbia un significato preciso.

FAQ

Quali plugin di DeepSeek Harness devo installare per primi su un VPS?

Installa prima dsh-budget e dsh-permission-rules. Un budget con overLimit: block impedisce a un'esecuzione non supervisionata di consumare risorse per tutta la notte, mentre un file .dsh/rules.yaml blocca una chiamata allo strumento che non avresti mai approvato. Aggiungi dsh-defend quando l'agente legge contenuti dal web pubblico e dsh-memory quando ti accorgi di incollare lo stesso contesto in ogni sessione. Evita temi e indicatori di stato: aggiungono codice eseguito con i privilegi dell'agente senza modificare il comportamento della macchina.

I plugin di dsh sono isolati dal harness?

No. Un plugin viene caricato nello stesso albero Cordis del harness, nello stesso processo e con lo stesso utente del sistema operativo, le stesse credenziali del modello e lo stesso albero di lavoro. Un plugin che intercetta tools/pre-execute vede e può bloccare ogni chiamata allo strumento; uno che intercetta agent/pre-step vede i tuoi messaggi. Leggi quindi il codice sorgente, verifica la licenza e la data dell'ultimo commit, quindi installa usando il commit anziché il branch, così il codice non può cambiare senza che tu lo sappia.

dsh-budget arresterà davvero l'agente o mi avviserà soltanto?

Dipende da overLimit. Il valore predefinito è alert: visualizza un avviso a warnRatio e continua a consumare risorse. block rifiuta ulteriori chiamate al modello una volta raggiunto il limite, mentre /budget unblock <scope> lo rimuove quando scegli di continuare. degrade blocca l'esecuzione e indica un modello meno costoso nella mappa degradation. Esiste un limite importante: nel commit bloccato 461d478, i totali vengono aggregati nel processo in esecuzione. Il riavvio del harness li azzera e un ciclo di riavvii può quindi eludere un limite giornaliero. La versione attuale main conserva per impostazione predefinita i contatori giornalieri e mensili tra i riavvii. In ogni caso, imposta un limite di spesa sull'account del provider: deve essere il limite effettivo massimo.

Come rimuovo completamente un plugin dsh?

Esegui dsh plugin --profile web remove <package-name>, conferma con dsh plugin --profile web list, quindi apri $DSH_HOME/profiles/web/cordis.patch.yml ed elimina ogni blocco di inserimento residuo relativo al plugin, perché è quella voce a caricarlo. Riavvia il harness per ricostruire l'albero dei plugin. I dati scritti dal plugin restano sul disco: sia $DSH_HOME/memory/memory.db sia .dsh/rules.yaml sopravvivono alla disinstallazione finché non li elimini manualmente.

È sicuro esporre l'interfaccia web di dsh sulla rete?

Non senza ulteriori misure. dsh web resta in ascolto su 127.0.0.1:3080, mentre dsh-web-lan-access modifica il binding in 0.0.0.0. Nel commit citato in questa guida, il relativo README dichiarava che in questo modo l'agente diventava raggiungibile senza autenticazione da chiunque si trovasse sulla stessa rete; soltanto settings.*, credentials.* e llm.discoverModels restavano vincolati al loopback. Le build attuali del harness, verificate il 10 October 2026, autenticano la sessione del browser con il launch token presente nell'URL stampato e con un cookie di sessione firmato. Tuttavia, la superficie di login viene esposta su ogni interfaccia e un URL HTTP semplice trasmette quel token in chiaro. Usa un port forwarding SSH, ssh -N -L 3080:127.0.0.1:3080 you@your-server, oppure colloca la porta dietro un'interfaccia di rete privata e una regola firewall. Metti sempre TLS davanti a qualsiasi servizio raggiungibile dall'esterno.