Publiceer je project

Als de knop Publish of Update "Your Cloud Balance is insufficient to publish" of "Your Cloud Balance is insufficient to update" toont, is je Cloud-portemonnee leeg.

Om dit op te lossen:

1. Ga naar Settings > Cloud & AI om je huidige saldo te controleren.

2. Selecteer Top up now en voeg saldo toe aan je Cloud-portemonnee.

3. Ga terug naar het Publish-paneel en probeer het opnieuw.

Opmerking: Je Cloud-portemonnee staat los van je abonnementscredits. De Cloud-portemonnee financiert hosting- en deploymentservices, terwijl abonnementscredits worden gebruikt voor AI Agent-gesprekken.

1. Controleer het overzicht van opslaggebruik en identificeer de grootste chats, projecten en bestanden.
2. Download of maak een back-up van alles wat je later mogelijk nodig hebt.
3. Verwijder alleen items die je niet nodig hebt. Als bij het verwijderen van chats wordt aangeboden om gekoppelde schijfdata te verwijderen, selecteer die optie dan alleen nadat je hebt bevestigd dat de data veilig kan worden weggegooid.
4. Vernieuw de pagina en controleer of de beschikbare opslag is toegenomen.
5. Ga terug naar Publish en probeer het nog één keer.

Verwijdering kan permanent zijn en kan een project kapotmaken dat verwijst naar een verwijderd bestand. Als het gebruik niet afneemt, neem dan contact op met Support met het opslagoverzicht, abonnement, projectlink en tijdstip van de mislukte publicatie.

Wacht tot de beveiligingsscan is voltooid en controleer daarna elk gemarkeerd item voordat je publiceert.

1. Selecteer Resolve All en inspecteer het betreffende gedrag. Los problemen met blootgestelde geheimen, authenticatie, machtigingen, gebruikersdata of onveilige externe toegang op voordat je het in productie gebruikt.
2. Als een geheim mogelijk is blootgesteld, verwijder het dan uit het project en roteer het via de relevante provider voordat je publiceert.
3. Voer de scan opnieuw uit en verifieer de betreffende flow.
4. Gebruik Publish Anyway alleen wanneer een verantwoordelijke beoordelaar het resterende, niet-kritieke risico begrijpt en accepteert. Leg de reden vast en vermijd het omzeilen van een onopgelost risico op een productiesite.

Als je de impact van een bevinding niet kunt bepalen, publiceer deze dan niet. Neem contact op met Support of je security-verantwoordelijke met de tekst van de bevinding en opgeschoond bewijsmateriaal.

1. Test de productie-URL van het platform en het aangepaste domein afzonderlijk. Vergelijk ook de hoofdpagina met de specifieke pagina of het API-pad dat faalt.
2. Noteer de exacte statuscode, volledige URL, tijd en tijdzone, en of de fout constant of intermitterend is.
3. Controleer de nieuwste deploymentstatus en of een recente wijziging in dependency, omgevingsvariabele, Database of externe service overeenkomt met het begin van de storing.
4. Leg relevante Console- en Network-fouten vast.

Als de storing aanhoudt, neem dan contact op met Support met reproductiestappen, de getroffen versie en opgeschoonde diagnostiek. Verwijder cookies, Authorization-headers, tokens, geheime queryparameters, persoonsgegevens en betaalinformatie voordat je een HAR, command-output of screenshot verstuurt.

Als je deployment een time-out krijgt of de live site tijdelijk niet beschikbaar is:

1. Controleer of zowel het Prod-subdomein van het platform als Preview niet toegankelijk zijn, of slechts één daarvan.

2. Laat de huidige foutpagina zichtbaar — klik niet herhaaldelijk op Publish.

3. Controleer of je recent dependencies, opstart-entrypoints of Database-verbindingen hebt gewijzigd, aangezien deze wijzigingen deployment kunnen beïnvloeden.

Als het probleem aanhoudt, neem dan contact op met Support en voeg het volgende toe:

- Projectlink en live URL

- Tijdstip van de storing en je tijdzone

- Versienummer en screenshot van de foutpagina

- Of Preview normaal werkt

- Of je recent dependencies, startup-entry of Database-verbinding hebt gewijzigd

Als het Publish-paneel "latest" toont met een grijze knop, of blijft hangen op "Building":

1. Klik niet herhaaldelijk op Publish — dit versnelt niets en kan dubbele buildtaken veroorzaken.

2. Wacht een paar minuten en vernieuw de pagina.

3. Als de status na het vernieuwen niet verandert, neem dan contact op met Support.

Voeg het volgende toe wanneer je contact opneemt met Support:

- Chatlink

- Volledige screenshot van het Publish-paneel (inclusief pagina-URL, versienummer en knopstatus)

- Tijdstip van optreden en je tijdzone

- Momenteel weergegeven versienummer

- Bij welke stap "Building" begon te verschijnen of de knop grijs werd

1. Controleer of de afbeelding ontbreekt in App Viewer, op de gepubliceerde site of op beide plaatsen.
2. Selecteer Reload App Viewer één keer. Als het probleem alleen op de live site voorkomt, bevestig dan dat de nieuwste versie is gepubliceerd of bijgewerkt.
3. Vertel de Agent welke pagina het betreft, welke afbeelding zou moeten verschijnen en waar de afbeelding oorspronkelijk vandaan kwam. Vraag om te controleren of het huidige project nog steeds de juiste afbeeldingsnaam en locatie gebruikt.
4. Als de oorspronkelijke afbeelding is verwijderd of hernoemd, upload of selecteer dan opnieuw de bedoelde afbeelding en test de pagina opnieuw.
5. Als de afbeelding App Opslag of een andere gekoppelde service gebruikt, bevestig dan dat de bedoelde service is gekoppeld en dat het bestand daar nog bestaat.

Als de afbeelding nog steeds niet laadt, neem dan contact op met Atoms Support met de Chat Link, de URL van de betreffende pagina, de afbeeldingsnaam of bron en een screenshot. Voeg geen privé-toegangslinks, wachtwoorden, sleutels of tokens toe.

Als het geëxporteerde self-host-pakket succesvol wordt gedownload maar niet kan worden uitgevoerd:

1. Controleer de README die in het exportpakket zit op omgevingsvereisten en installatiestappen.

2. Controleer of je runtime-omgeving overeenkomt met de vereisten (OS-versie, Docker-versie, Node.js-versie).

3. Voer het opstartcommando uit en bekijk de volledige output op foutmeldingen.

Als het probleem aanhoudt, neem dan contact op met Support en voeg het volgende toe:

- Exportversie en downloadtijd

- Gebruikt OS en Docker-versie

- Volledig uitgevoerd commando en volledige output

- Mislukt script of API-pad

- Verwachte deploymentmethode

Belangrijk: Voeg een opgeschoond configuratievoorbeeld toe, maar voeg GEEN wachtwoorden, geheimen of tokens toe.

App Viewer en de gepubliceerde site tonen verschillende fasen van je project. Het opslaan van een visuele wijziging werkt de live site niet automatisch bij.

1. Selecteer in Design Save en wacht tot de huidige Agent-taak of build is voltooid.
2. Open Publish. Publiceren gebruikt de nieuwste projectversie; er is geen versiekeuzelijst in het Publish-paneel.
3. Selecteer Publish voor de eerste release of Update voor een latere release. Wacht tot het paneel Up to date toont.
4. Open de live site in een nieuw tabblad en laad deze één keer opnieuw.
5. Als het standaard Atoms-adres de wijziging toont maar een aangepast domein niet, controleer dan de domeinkoppeling in plaats van dezelfde versie herhaaldelijk te publiceren.

Als de live site nog steeds de verkeerde versie toont, neem dan contact op met Atoms Support met de Chat Link, de live URL, de versie die je wilde publiceren, de tijd en tijdzone, en screenshots van App Viewer en de live site.

1. Beperk direct risico. Als de release gevoelige data blootstelt of onveilig gedrag veroorzaakt, open dan App Status en gebruik Pause voor een geschikte Atoms Cloud-app of Unpublish om openbare toegang te verwijderen. Als er geen actief risico is, voorkom dan onnodige uitval.
2. Noteer het getroffen domein, het tijdstip van publicatie, de huidige versie, de bedoelde versie en de zakelijke impact.
3. Nadat de huidige Agent-taak is gestopt, open je Versions, kies je de laatst bekende goede versie en selecteer je Restore this version.
4. Controleer de herstelde versie in Preview, inclusief kritieke login-, betaal- en dataflows, en publiceer of werk deze daarna bij.

Het herstellen van een projectversie maakt wijzigingen in de productie-Database of externe acties mogelijk niet ongedaan. Overschrijf of verwijder geen productiedata om een rollback na te bootsen. Neem onmiddellijk contact op met Support wanneer data, inloggegevens, betalingen of destructieve wijzigingen betrokken zijn.

1. Stop of wacht op de huidige Agent-taak; een versie kan niet worden hersteld terwijl conflicterend werk actief is.
2. Open Versions, zoek de laatst bekende goede versie en selecteer Restore this version.
3. Controleer het herstelde project in Preview en test de kritieke flows die zijn gewijzigd.
4. Publiceer of werk pas bij nadat het resultaat in Preview correct is.

Het herstellen van een projectversie draait productie-Database-records, schemawijzigingen, omgevingsvariabelen, betalingen, e-mails of andere externe acties niet noodzakelijk terug. Als de release productiedata heeft gewijzigd of de doelversie niet beschikbaar is, stop dan en neem contact op met Support met beide versienummers, het getroffen domein en het vereiste resultaat voor databehoud.

Pause en Unpublish zijn twee verschillende acties:

Pause (alleen Atoms Cloud-projecten):

- De app wordt onbeschikbaar voor bezoekers.

- Serverresources blijven toegewezen en facturering loopt door.

- Je kunt de app op elk moment hervatten vanuit App Status.

Unpublish (alle projecten):

- De website gaat volledig offline. Iedereen die de gepubliceerde URL gebruikt, verliest toegang.

- Voor Atoms Cloud-projecten worden serverresources vrijgegeven.

- Je kunt het project later opnieuw publiceren, maar bezoekers hebben geen toegang totdat je dat doet.

Gebruik Pause voor een tijdelijke verwijdering met snelle herstart. Gebruik Unpublish om de site volledig te verwijderen.

Als je browser "too many redirects" toont of de pagina blijft herladen zonder content weer te geven:

1. Probeer het standaard Prod-subdomein van het platform (niet je aangepaste domein) om te bepalen of de redirectlus wordt veroorzaakt door de domeinconfiguratie of door de applicatie zelf.
2. Als het standaard Prod-subdomein werkt, controleer dan de DNS-instellingen van je aangepaste domein en je domeinregistrar op redirectregels die mogelijk conflicteren met het platform.
3. Wis je browsercache of test in een incognitovenster om gecachte redirects uit te sluiten.

Als het probleem aanhoudt, neem dan contact op met Support en voeg het volgende toe:

- Volledige URL die de redirectlus toont

- Of het standaard Prod-subdomein toegankelijk is

- Domeinnaam en DNS-provider

- Volledige screenshot van de fout

Als je app werkt in Preview maar faalt in productie door ontbrekende of lege omgevingsvariabelen:

1. Controleer of de omgevingsvariabele vóór of na de laatste publicatie is opgeslagen. Als deze daarna is opgeslagen, moet je opnieuw publiceren voordat de wijziging effect heeft.
2. Controleer of de variabele is ingesteld voor de juiste omgeving (Development vs. Production).
3. Controleer of de foutmelding van de downstreamservice een aanwijzing geeft — bijvoorbeeld betekent "unauthorized" vaak dat een API-sleutel in die omgeving leeg of onjuist is.

Als het probleem aanhoudt, neem dan contact op met Support en voeg het volgende toe:

- Projectlink of live URL

- De naam van de betreffende sleutel en in welke omgeving het probleem optreedt

- De volledige fout van de downstreamservice

- Een opgeschoonde screenshot van de configuratiepagina

- Of de configuratie vóór of na het publiceren is opgeslagen

Belangrijk: Geef alleen sleutelnamen door. Verstuur GEEN geheime waarden, wachtwoorden of tokens.

Bevindingen kunnen vergelijkbare formuleringen gebruiken terwijl ze naar verschillende locaties verwijzen. Vergelijkbare formuleringen betekenen niet noodzakelijk dat de resultaten duplicaten zijn.

1. Vergelijk de naam van de bevinding en de locatie die voor elk resultaat wordt getoond.
2. Controleer elke unieke locatie in plaats van de herhaalde formulering te negeren.
3. Als meerdere bevindingen dezelfde onderliggende oorzaak hebben, los die oorzaak dan op en controleer daarna elke locatie opnieuw.
4. Voer de beveiligingsscan opnieuw uit op de bijgewerkte versie.

Als dezelfde bevinding en locatie nog steeds meer dan één keer verschijnen, neem dan contact op met Atoms Support met de Chat Link, scantijd en tijdzone, aantal bevindingen en een geredigeerde screenshot. Verwijder wachtwoorden, sleutels, tokens of andere gevoelige informatie die in een bevinding kunnen voorkomen.

Een voltooide scan zonder gemelde bevindingen is een nuttige controle, maar kan niet garanderen dat elk beveiligings- of runtimeprobleem is gevonden. De scan controleert de geselecteerde projectversie; je app moet nog steeds worden getest op de manier waarop echte gebruikers deze zullen gebruiken.

Test vóór het publiceren de belangrijke gebruikersreizen in je app, inclusief aanmelden, gebruikersrollen, toegang tot privédata, betalingen en gekoppelde services. Gebruik aparte testaccounts voor verschillende rollen en bevestig dat elk account alleen toegang heeft tot de informatie en acties die ervoor bedoeld zijn.

Als je een productieprobleem ontdekt dat accounts, privédata, betalingen of inloggegevens kan blootstellen, stop dan eerst met het gebruik van de betreffende functie of beperk de toegang ertoe. Roteer alle inloggegevens die mogelijk zijn blootgesteld en neem daarna contact op met Atoms Support met de Chat Link, de getroffen versie, stappen om het probleem te reproduceren, tijd en tijdzone, en een geredigeerde screenshot. Deel de blootgestelde inloggegevens zelf niet.

Als de scan meldt dat een actie alleen voor admins mogelijk onbeveiligd is, behandel de bevinding dan als onopgelost totdat je bevestigt dat onbevoegde gebruikers deze niet kunnen gebruiken. Het verbergen van een admin-knop is niet voldoende als de actie nog steeds op een andere manier kan worden aangevraagd.

1. Open de bevinding en identificeer de actie of locatie die erin wordt genoemd.
2. Bepaal welke aangemelde rollen die actie mogen gebruiken.
3. Vraag de Agent om de machtiging van de gebruiker te controleren wanneer de actie wordt aangevraagd, niet alleen wanneer de knop wordt weergegeven.
4. Test de actie terwijl je bent uitgelogd, met een normaal testaccount en met een geautoriseerd admin-testaccount.
5. Bevestig dat afgewezen pogingen geen privédata onthullen en geen wijzigingen aanbrengen, en voer daarna de beveiligingsscan opnieuw uit.

Publiceer de betreffende functie niet als een onbevoegd account de actie nog steeds kan gebruiken. Neem contact op met Atoms Support met de Chat Link, de tekst van de bevinding, de getroffen versie en een geredigeerde screenshot als je het niet kunt oplossen.

HTTPS beschermt informatie terwijl deze tussen een gebruiker en een service reist. Als de scan een HTTPS-probleem meldt, gebruik dan de exacte bevinding om het betreffende adres, de resource, callback of domeinconfiguratie te identificeren.

1. Open de bevinding en noteer de exacte locatie en het adres dat wordt gemeld.
2. Vraag de Agent om die specifieke verbinding te vervangen door het beveiligde adres dat door de provider wordt ondersteund, of om de gerelateerde domeinconfiguratie te corrigeren.
3. Negeer certificaatwaarschuwingen niet en wijzig een adres niet zomaar als de externe service geen beveiligd equivalent documenteert.
4. Test de betreffende gebruikersreis opnieuw en bevestig dat er geen wachtwoord, token, betaalgegeven of privé-informatie via een onbeveiligde verbinding wordt verzonden.
5. Voer de beveiligingsscan opnieuw uit op de bijgewerkte versie.

Als de bevinding betrekking heeft op een aangepast domein of certificaat dat je niet kunt corrigeren, neem dan contact op met Atoms Support met de Chat Link, de getroffen URL, de tekst van de bevinding, tijd en tijdzone, en een geredigeerde screenshot.

Row Level Security, of RLS, is een Supabase-functie die bepaalt welke Database-rijen elke gebruiker kan lezen of wijzigen. Deze bevinding is alleen relevant wanneer het project Supabase gebruikt en de scan een tabel identificeert waarvan de toegangsregels moeten worden gecontroleerd.

1. Open de bevinding en identificeer de tabel die erin wordt genoemd.
2. Schrijf op wie de data in die tabel moet kunnen bekijken, toevoegen, bewerken of verwijderen.
3. Vraag de Agent om de minst permissieve Supabase-beleidsregels te maken die deze gebruikersreizen ondersteunen.
4. Test terwijl je bent uitgelogd en met een apart testaccount voor elke rol. Bevestig dat elk account alleen toegang heeft tot de bedoelde rijen en acties.
5. Voer de beveiligingsscan opnieuw uit nadat de beleidsregels zijn toegepast.

Schakel RLS niet uit en geef niet elke gebruiker toegang alleen om de waarschuwing te verwijderen. Bevestig het plan en bewaar waar nodig een veilige back-up of export voordat je een wijziging aanbrengt die bestaande data kan beïnvloeden. Deel nooit Supabase-sleutels of Database-inloggegevens in Chat of screenshots.