Publicera ditt projekt

Om knappen Publish eller Update visar "Your Cloud Balance is insufficient to publish" eller "Your Cloud Balance is insufficient to update," har din Cloud-plånbok tagit slut.

Så här åtgärdar du det:

1. Gå till Settings > Cloud & AI för att kontrollera ditt nuvarande saldo.

2. Välj Top up now och lägg till pengar i din Cloud-plånbok.

3. Gå tillbaka till panelen Publish och försök igen.

Obs! Din Cloud-plånbok är separat från dina prenumerationskrediter. Cloud-plånboken finansierar hosting- och distributionstjänster, medan prenumerationskrediter används för AI-agentkonversationer.

1. Kontrollera vyn för lagringsanvändning och identifiera de största chattarna, projekten och filerna.
2. Ladda ned eller säkerhetskopiera allt du kan behöva senare.
3. Ta bara bort sådant som inte behövs. Om borttagning av chatt erbjuder att ta bort associerade diskdata, välj det alternativet först efter att du har bekräftat att datan säkert kan kasseras.
4. Uppdatera sidan och bekräfta att tillgängligt lagringsutrymme har ökat.
5. Gå tillbaka till Publish och försök igen en gång.

Borttagning kan vara permanent och kan göra att ett projekt som refererar till en borttagen fil slutar fungera. Om användningen inte minskar, kontakta Support med lagringsvyn, planen, projektlänken och tiden för den misslyckade publiceringen.

Vänta tills säkerhetsskanningen är klar och granska sedan varje markerad post innan du publicerar.

1. Välj Resolve All och inspektera det påverkade beteendet. Åtgärda problem som rör exponerade hemligheter, autentisering, behörigheter, användardata eller osäker extern åtkomst innan användning i produktion.
2. Om en hemlighet kan ha exponerats, ta bort den från projektet och rotera den hos den relevanta leverantören innan publicering.
3. Kör skanningen igen och verifiera det påverkade flödet.
4. Använd Publish Anyway endast när en ansvarig granskare förstår och accepterar den återstående, icke-kritiska risken. Dokumentera orsaken och undvik att kringgå en olöst risk på en produktionswebbplats.

Om du inte kan avgöra påverkan av ett resultat, publicera inte. Kontakta Support eller din säkerhetsansvarige med resultattexten och sanerad bevisning.

1. Testa plattformens produktions-URL och den anpassade domänen separat. Jämför också rotsidan med den specifika sidan eller API-sökvägen som misslyckas.
2. Registrera den exakta statuskoden, fullständig URL, tid och tidszon samt om felet är konstant eller intermittent.
3. Kontrollera den senaste distributionsstatusen och om en nylig ändring av beroenden, miljövariabler, databas eller extern tjänst sammanfaller med när felet började.
4. Fånga relevanta Console- och Network-fel.

Om felet kvarstår, kontakta Support med steg för att återskapa problemet, den påverkade versionen och sanerad diagnostik. Innan du skickar en HAR-fil, kommandoutdata eller skärmbild, ta bort cookies, Authorization-rubriker, tokenar, hemliga frågeparametrar, personuppgifter och betalningsinformation.

Om din distribution får timeout eller den livepublicerade webbplatsen tillfälligt är otillgänglig:

1. Kontrollera om både plattformens Prod-underdomän och Preview är otillgängliga, eller bara en av dem.

2. Låt den aktuella felsidan vara synlig — klicka inte upprepade gånger på Publish.

3. Kontrollera om du nyligen ändrade beroenden, startpunkter eller databasanslutningar, eftersom dessa ändringar kan påverka distributionen.

Om problemet kvarstår, kontakta Support och inkludera:

- Projektlänk och live-URL

- Tid för felet och din tidszon

- Versionsnummer och skärmbild av felsidan

- Om Preview fungerar normalt

- Om du nyligen ändrade beroenden, startpunkt eller databasanslutning

Om panelen Publish visar "latest" med knappen nedtonad, eller har fastnat på "Building":

1. Klicka inte upprepade gånger på Publish — det gör inte processen snabbare och kan skapa dubbla bygguppgifter.

2. Vänta några minuter och uppdatera sidan.

3. Om statusen inte ändras efter uppdatering, kontakta Support.

Inkludera följande när du kontaktar Support:

- Chattlänk

- Fullständig skärmbild av panelen Publish (inklusive sidans URL, versionsnummer och knappstatus)

- Tidpunkt för händelsen och din tidszon

- Versionsnumret som visas just nu

- Vid vilket steg den började visa "Building" eller knappen blev nedtonad

1. Kontrollera om bilden saknas i App Viewer, på den publicerade webbplatsen eller på båda ställena.
2. Välj Reload App Viewer en gång. Om problemet bara finns på den livepublicerade webbplatsen, bekräfta att den senaste versionen har publicerats eller uppdaterats.
3. Berätta för Agent vilken sida det gäller, vilken bild som ska visas och var bilden ursprungligen kom ifrån. Be den kontrollera att det aktuella projektet fortfarande använder rätt bildnamn och plats.
4. Om originalbilden togs bort eller bytte namn, ladda upp eller välj den avsedda bilden igen och testa sedan sidan på nytt.
5. Om bilden använder App Storage eller en annan ansluten tjänst, bekräfta att den avsedda tjänsten är ansluten och att filen fortfarande finns där.

Om bilden fortfarande inte laddas, kontakta Atoms Support med Chat Link, den påverkade sidans URL, bildnamnet eller källan och en skärmbild. Inkludera inte privata åtkomstlänkar, lösenord, nycklar eller tokenar.

Om det exporterade self-host-paketet laddas ned korrekt men inte går att köra:

1. Kontrollera README-filen som ingår i exportpaketet för miljökrav och installationssteg.

2. Verifiera att din runtime-miljö matchar kraven (OS-version, Docker-version, Node.js-version).

3. Kör startkommandot och granska hela utdata efter felmeddelanden.

Om problemet kvarstår, kontakta Support och inkludera:

- Exportversion och nedladdningstid

- Operativsystem och Docker-version som används

- Fullständigt kommando som kördes och fullständig utdata

- Misslyckat skript eller API-sökväg

- Förväntad distributionsmetod

Viktigt: Bifoga ett sanerat konfigurationsexempel, men inkludera INTE lösenord, hemligheter eller tokenar.

App Viewer och den publicerade webbplatsen visar olika stadier av ditt projekt. Att spara en visuell ändring uppdaterar inte den livepublicerade webbplatsen av sig själv.

1. I Design, välj Save och vänta tills den aktuella Agent-uppgiften eller bygget är klart.
2. Öppna Publish. Publicering använder den senaste projektversionen; det finns ingen versionsväljare i panelen Publish.
3. Välj Publish för den första utgåvan eller Update för en senare utgåva. Vänta tills panelen visar Up to date.
4. Öppna den livepublicerade webbplatsen i en ny flik och ladda om den en gång.
5. Om standardadressen från Atoms visar ändringen men en anpassad domän inte gör det, kontrollera domänanslutningen i stället för att publicera samma version upprepade gånger.

Om den livepublicerade webbplatsen fortfarande visar fel version, kontakta Atoms Support med Chat Link, live-URL:en, versionen du avsåg att publicera, tid och tidszon samt skärmbilder från App Viewer och den livepublicerade webbplatsen.

1. Begränsa den omedelbara risken. Om utgåvan exponerar känsliga data eller skapar osäkert beteende, öppna App Status och använd Pause för en kvalificerad app i Atoms moln eller Unpublish för att ta bort offentlig åtkomst. Om det inte finns någon aktiv risk, undvik att orsaka ett onödigt avbrott.
2. Registrera den påverkade domänen, publiceringstiden, aktuell version, avsedd version och affärspåverkan.
3. När den aktuella agentuppgiften har stoppats, öppna Versions, välj den senaste kända fungerande versionen och välj Restore this version.
4. Verifiera den återställda versionen i Preview, inklusive kritiska flöden för inloggning, betalning och data, och publicera eller uppdatera den sedan.

Att återställa en projektversion kanske inte återställer ändringar i produktionsdatabasen eller externa åtgärder. Skriv inte över eller ta inte bort produktionsdata för att efterlikna en rollback. Kontakta Support omedelbart när data, autentiseringsuppgifter, betalningar eller destruktiva ändringar är inblandade.

1. Stoppa eller vänta på den aktuella agentuppgiften; en version kan inte återställas medan motstridigt arbete pågår.
2. Öppna Versions, hitta den senaste kända fungerande versionen och välj Restore this version.
3. Granska det återställda projektet i Preview och testa de kritiska flöden som ändrades.
4. Publicera eller uppdatera först när resultatet i Preview är korrekt.

En återställning av projektversion återställer inte nödvändigtvis produktionsdatabasposter, schemaändringar, miljövariabler, betalningar, e-postmeddelanden eller andra externa åtgärder. Om utgåvan ändrade produktionsdata eller målversionen inte är tillgänglig, stoppa och kontakta Support med båda versionsnumren, den påverkade domänen och det önskade resultatet för databevarande.

Pause och Unpublish är två olika åtgärder:

Pause (endast projekt i Atoms moln):

- Appen blir otillgänglig för besökare.

- Serverresurser förblir allokerade och faktureringen fortsätter.

- Du kan återuppta appen när som helst från App Status.

Unpublish (alla projekt):

- Webbplatsen går helt offline. Alla som använder den publicerade URL:en förlorar åtkomst.

- För projekt i Atoms moln frigörs serverresurser.

- Du kan publicera projektet igen senare, men besökare kan inte komma åt det förrän du gör det.

Använd Pause för en tillfällig nedtagning med snabb omstart. Använd Unpublish för att ta bort webbplatsen helt.

Om din webbläsare visar "too many redirects" eller sidan fortsätter att laddas om utan att visa innehåll:

1. Prova plattformens standardiserade Prod-underdomän (inte din anpassade domän) för att avgöra om omdirigeringsloopen orsakas av domänkonfigurationen eller av själva applikationen.
2. Om standardiserade Prod-underdomänen fungerar, kontrollera DNS-inställningarna för din anpassade domän och din domänregistrator för omdirigeringsregler som kan stå i konflikt med plattformen.
3. Rensa webbläsarens cache eller testa i ett inkognitofönster för att utesluta cachade omdirigeringar.

Om problemet kvarstår, kontakta Support och inkludera:

- Fullständig URL som visar omdirigeringsloopen

- Om standardiserade Prod-underdomänen är tillgänglig

- Domännamn och DNS-leverantör

- Fullständig skärmbild av felet

Om din app fungerar i Preview men misslyckas i produktion på grund av saknade eller tomma miljövariabler:

1. Kontrollera om miljövariabeln sparades före eller efter den senaste publiceringen. Om den sparades efteråt måste du publicera igen för att ändringen ska träda i kraft.
2. Verifiera att variabeln är inställd för rätt miljö (Development vs. Production).
3. Kontrollera om felmeddelandet från den nedströms tjänsten ger en ledtråd — till exempel betyder "unauthorized" ofta att en API-nyckel är tom eller felaktig i den miljön.

Om problemet kvarstår, kontakta Support och inkludera:

- Projektlänk eller live-URL

- Namnet på den påverkade nyckeln och vilken miljö som har problemet

- Det fullständiga felet från den nedströms tjänsten

- En sanerad skärmbild av konfigurationssidan

- Om konfigurationen sparades före eller efter publicering

Viktigt: Ange endast nyckelnamn. Skicka INTE hemliga värden, lösenord eller tokenar.

Resultat kan använda liknande formuleringar samtidigt som de pekar på olika platser. Liknande formuleringar betyder inte nödvändigtvis att resultaten är dubbletter.

1. Jämför namnet på resultatet och platsen som visas för varje resultat.
2. Granska varje unik plats i stället för att avfärda den upprepade formuleringen.
3. Om flera resultat har samma underliggande orsak, åtgärda den orsaken och kontrollera sedan varje plats igen.
4. Kör säkerhetsskanningen igen på den uppdaterade versionen.

Om samma resultat och plats fortfarande visas mer än en gång, kontakta Atoms Support med Chat Link, skanningstid och tidszon, antal resultat och en redigerad skärmbild. Ta bort eventuella lösenord, nycklar, tokenar eller annan känslig information som kan visas i ett resultat.

En slutförd skanning utan rapporterade resultat är en användbar kontroll, men den kan inte garantera att alla säkerhets- eller runtime-problem har hittats. Skanningen kontrollerar den valda projektversionen; din app måste fortfarande testas på det sätt som riktiga användare kommer att använda den.

Innan publicering, testa de viktiga användarresorna i din app, inklusive inloggning, användarroller, åtkomst till privata data, betalningar och anslutna tjänster. Använd separata testkonton för olika roller och bekräfta att varje konto endast kan komma åt den information och de åtgärder som är avsedda för det.

Om du upptäcker ett produktionsproblem som kan exponera konton, privata data, betalningar eller autentiseringsuppgifter, sluta först använda eller begränsa åtkomsten till den påverkade funktionen. Rotera alla autentiseringsuppgifter som kan ha exponerats och kontakta sedan Atoms Support med Chat Link, påverkad version, steg för att återskapa problemet, tid och tidszon samt en redigerad skärmbild. Dela inte själva den exponerade autentiseringsuppgiften.

Om skanningen rapporterar att en åtgärd endast för administratörer kan vara oskyddad, behandla resultatet som olöst tills du har bekräftat att obehöriga användare inte kan använda den. Att dölja en administratörsknapp räcker inte om åtgärden fortfarande kan begäras på ett annat sätt.

1. Öppna resultatet och identifiera åtgärden eller platsen som det nämner.
2. Bestäm vilka inloggade roller som ska få använda den åtgärden.
3. Be Agent kontrollera användarens behörighet när åtgärden begärs, inte bara när knappen visas.
4. Testa åtgärden när du är utloggad, med ett vanligt testkonto och med ett auktoriserat administratörstestkonto.
5. Bekräfta att avvisade försök inte avslöjar privata data och inte gör några ändringar, och kör sedan säkerhetsskanningen igen.

Publicera inte den påverkade funktionen om ett obehörigt konto fortfarande kan använda åtgärden. Kontakta Atoms Support med Chat Link, resultattext, påverkad version och en redigerad skärmbild om du inte kan lösa det.

HTTPS skyddar information medan den färdas mellan en användare och en tjänst. Om skanningen rapporterar ett HTTPS-problem, använd det exakta resultatet för att identifiera den påverkade adressen, resursen, callbacken eller domänkonfigurationen.

1. Öppna resultatet och notera den exakta platsen och adressen som rapporteras.
2. Be Agent ersätta just den anslutningen med den säkra adress som stöds av dess leverantör, eller korrigera den relaterade domänkonfigurationen.
3. Ignorera inte certifikatvarningar och ändra inte en adress blint om den externa tjänsten inte dokumenterar en säker motsvarighet.
4. Testa den påverkade användarresan igen och bekräfta att inget lösenord, token, betalningsuppgift eller privat information skickas över en osäker anslutning.
5. Kör säkerhetsskanningen igen på den uppdaterade versionen.

Om resultatet gäller en anpassad domän eller ett certifikat som du inte kan korrigera, kontakta Atoms Support med Chat Link, påverkad URL, resultattext, tid och tidszon samt en redigerad skärmbild.

Row Level Security, eller RLS, är en Supabase-funktion som styr vilka databasrader varje användare kan läsa eller ändra. Detta resultat är endast relevant när projektet använder Supabase och skanningen identifierar en tabell vars åtkomstregler behöver granskas.

1. Öppna resultatet och identifiera tabellen som det nämner.
2. Skriv ned vem som ska kunna visa, lägga till, redigera eller ta bort den tabellens data.
3. Be Agent skapa de minst tillåtande Supabase-policyerna som stöder dessa användarresor.
4. Testa när du är utloggad och med ett separat testkonto för varje roll. Bekräfta att varje konto endast kan komma åt de avsedda raderna och åtgärderna.
5. Kör säkerhetsskanningen igen efter att policyerna har tillämpats.

Inaktivera inte RLS och tillåt inte alla användare bara för att rensa varningen. Innan du gör en ändring som kan påverka befintliga data, bekräfta planen och behåll en säker säkerhetskopia eller export där det är lämpligt. Dela aldrig Supabase-nycklar eller databasautentiseringsuppgifter i Chat eller skärmbilder.