Questa è la FAQ canonica del sito. Le altre pagine possono collegarla, ma non dovrebbero creare raccolte parallele con risposte differenti.
Fliclic è un progetto per creare e gestire ambienti web destinati soprattutto a sviluppo, test, demo, debug e copie di lavoro. Unisce Fliclic DEV, usato dallo sviluppatore, e Fliclic Server, il motore tecnico che esegue e controlla le operazioni.
No. Usa componenti tipici dell'hosting, ma è organizzato intorno al ciclo di lavoro dello sviluppatore. Un ambiente può essere temporaneo, una demo o un master riutilizzabile.
Il progetto comprende workflow reali per ambienti, database, PHP, WordPress, duplicazioni, quote, backup e restore, con verifiche runtime documentate. È ancora in evoluzione e mantiene visibili funzioni e limiti non completati.
No. Fliclic DEV è il servizio che usa lo sviluppatore. Fliclic Server è il motore infrastrutturale che lo rende possibile.
In primo luogo a sviluppatori freelance, web agency e team tecnici che hanno bisogno di uno spazio separato dalla produzione. Un cliente può vedere una demo senza dover amministrare l'infrastruttura.
Questo è uno dei casi d'uso del progetto.
Sì, concettualmente un ambiente può essere conservato come base da duplicare. “Master” è un modo d'uso, non un tipo tecnico con versionamento automatico. Conservazione e limiti dipendono dalle condizioni del servizio.
Puoi trasferire file via SFTP e lavorare sui database con gli strumenti disponibili. Nel codice server analizzato non esiste però un unico workflow di importazione one-click valido per qualsiasi provider o applicazione.
Sì, è un caso d'uso centrale: la demo vive in un ambiente separato e può essere modificata o rimossa senza agire sul sito originale.
La disponibilità dipende dal nodo e dalla policy corrente. Le versioni DEV possono includere runtime legacy per compatibilità, ma ciò non garantisce la stessa disponibilità in altri ambienti.
No. Il sistema cambia il runtime e conserva la configurazione gestita, ma non verifica tutte le funzioni dell'applicazione. Estensioni, patch e dipendenze esterne devono essere testate.
Sì, il progetto include un workflow di installazione WordPress. La compatibilità di temi, plugin e codice personalizzato resta responsabilità del progetto applicativo.
La destinazione riceve file e database propri. Un workflow dedicato riallinea credenziali, URL e riferimenti necessari alla copia. Il restore non usa questo workflow e non riscrive WordPress.
Il motore gestisce database aggiuntivi e duplicazioni.
No. La destinazione ha identità, quota, pool PHP e database propri. Le modifiche sulla copia non sono sincronizzate automaticamente con la sorgente.
No. Coinvolge provisioning, filesystem e database. Un errore può lasciare una destinazione parziale; lo stato consente di distinguerla da una copia conclusa e può essere necessario ricrearla.
HOT lascia l'ambiente operativo e non crea una fotografia atomica tra file e database. STOP indirizza temporaneamente le richieste web a una pagina tecnica e riduce le scritture HTTP, ma non ferma necessariamente SFTP, job o processi già avviati.
Contenuto pubblico, dump dei database attivi catturati e uno snapshot protetto con identità, metadati, hash e credenziali storiche necessarie al restore.
Nel modello corrente sono locali al nodo e fanno parte dello spazio del servizio. Non sono copie off-site e non proteggono dalla perdita dell'intera VPS o del filesystem.
No. È fotografico: sostituisce il contenuto pubblico con quello del backup. Anche i database attivi successivi e non presenti nella fotografia vengono eliminati.
No. Se lo stato corrente deve essere conservato, occorre creare consapevolmente una copia o un backup prima di avviare il ripristino.
No. È CMS-agnostico e non esegue search-replace o riscritture applicative. Ripristina la fotografia e applica soltanto la policy infrastrutturale sui metadata.
No. La versione viene registrata come metadato per diagnosi, ma il runtime resta quello corrente. Un motore tenant-safe per il ripristino automatico della versione è una direzione futura, non una funzione disponibile.
No. Il restore automatico richiede lo snapshot compatibile, gli artefatti integri e lo storico database necessario. Un archivio legacy privo di manifest non viene adattato con euristiche.
Prima della distruzione, il preflight lascia intatti file e database correnti. Dopo l'inizio, un errore può lasciare una ricostruzione parziale; il sistema tenta di mantenere l'ambiente isolato e registra la diagnosi. Non esiste retry automatico universale.
Usano utenti, gruppi, pool PHP-FPM, socket, database e permessi dedicati. Condividono tuttavia kernel, filesystem, Apache e master PHP-FPM della stessa versione: non sono macchine virtuali o container indipendenti.
SFTP è confinato nella home dell'ambiente e non offre una shell generale. Permessi e gruppi impediscono l'attraversamento ordinario tra tenant; operazioni privilegiate recenti usano traversate no-follow e descriptor-relative.
Sì, Project Quota applica limiti a spazio e inode dell'intero albero del servizio, inclusi backup, log e temporanei. Non limita automaticamente database, CPU, RAM o processi.
I nuovi flussi di backup e restore usano file temporanei protetti. Alcune catene storiche devono ancora essere riallineate allo stesso modello; la separazione tra utenti e la visibilità limitata dei processi costituiscono una barriera aggiuntiva, ma il lavoro non è dichiarato concluso.
Il modello corrente richiede TLS e account di automazione limitati. La verifica completa dell'identità dell'endpoint richiede un ulteriore allineamento di hostname e certificato e non viene presentata come già conclusa.
Il progetto nasce per offrire ambienti gratuiti agli sviluppatori.
La pagina “Accesso, gratuità e condizioni” sarà la fonte aggiornata.
Non risultano tempi di risposta o SLA pubblici definiti.
Non oggi sulla base del progetto disponibile. Non risultano un installer pubblico, una distribuzione autonoma o una guida completa di amministrazione. Fliclic Server è il motore del servizio Fliclic.
Non nello stesso senso. Non vuole esporre ogni funzione amministrativa di un server. Coordina le azioni necessarie agli ambienti Fliclic e mantiene l'esperienza centrata sul progetto.
No. I tempi citati derivano da scenari di test specifici e servono a documentare il metodo di ottimizzazione. Non sono SLA o benchmark universali.
