Announcement: we are testing static pages on and are looking for feedback. How this works:

In your user or org account, create repo called "pages", and push static HTML, Javascript, fonts, CSS, images into this repo. Your content is immediately visible on<username>/​.

For an example, check out and

Thanks to @KBoesefeldt for pushing us to this and helping us to set it up! And while you are there, please support the initiative!

Thanks back to @codeberg for supporting #webIsOurs with the migration to Please notice that the test-site is not yet official, the full migration will take some more days.

@codeberg where will be the best place to recommend changes to this feature? I assume you have a repo set up?

@codeberg works. the content is instantly available!

Do you have a plan for repo pages? Or should one use a organization for every project that needs a website? That would be quiet complex for small projects, but maybe also a good practice?

I don't think it makes sense to commit build products (like static HTML) in the same repository as the source, like needed for github pages.

@davidak as creating a user/repo/ subpage is redundant with a dedicated repo page, we thought this would be the simpler approach.

(and having a separate pages repo wont clutter the code repo history with microcommits from the WYSIWYG editor) ...

we would like to hear your thoughts on this tho!

@codeberg @davidak

Microcommits should be rebased or squashed, and always tested out of master. That shouldn't be a problem.

I like more the procedure of gitlab, where I put, for example, Jekyll files and they get compiled to HTML and served in a repo page. I see two advantages:

1. When changing the header, footer or any piece of code repeated along every page, the set of changes is one file. On the other hand, if I upload the HTML directly, the set of changes is all files. The commit history of the pages repo wouldn't make sense.

2. There can be a page served for every repo, without need to create organizations. I prefer to be able to create as many page repos as I want than to be limited to one.

I hope this opinion helps.

@josealberto4444 @davidak big thank you for this feedback!

A question to clarify: As you consider the jekyll sources part of your project, wouldn't having the Jekyll sources in your code repo and "deploying" the generated HTML to pages be the consistent approach, giving you the benefits you are asking for?

@josealberto4444 @davidak

Put differently, the pages repo is merely a compressed, versioned storage facility for efficient delivery, not so much meant for human inspection (albeit you always can!).

It is by no means intended as full replacement for the development process. Especially when compiling from higher-level markup like Jekyll or Hugo (and the user is free to pick the framework of his choice), maintaining the code in a code repo makes much more sense.

@josealberto4444 @davidak regarding (3), there is no need to create an org, also a user can always have any number of subpages in his pages repo:

From the browser point of view, the URL hierarchy would be the same as for per-repo pages, or do you have a different layout in mind?

@codeberg @davidak Ah… I see your point.

I feel it's kind of dirty to have a page repo, as the version controlling is a bit useless, but I agree it's not as bad as I thought. =P Could be OK, hahaha.

@josealberto4444 @codeberg yeah, that's also what i think. I usually have a source repofor my pages. An elegant technical solution is to have a CI that builds and deploys it to a server. Codeberg could just offer free webspace for static sites with SSH, SFTP and WEBDAV access. But like i said, there is for that. When codeberg would have a CI, it could support publishing the site with it to a separate server. GitLab probably does it this way (i havn't used that).

@codeberg I can't see the content of your /etc/shadow by uploading a symlink to it.

Any other idea what nasty things someone can come up with?

Good you don't support .htaccess :D

@davidak :) hehe, nice try!

Please also have a look at the implementation and let us know if you can imagine any possible exploits:

Sign in to participate in the conversation
Mastodon for Tech Folks

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!