Merge pull request #212 from zgoat/sessions
Add session tracking
|22 hours ago|
|.github||2 weeks ago|
|acme||1 month ago|
|cfg||3 weeks ago|
|cmd/goatcounter||23 hours ago|
|cron||22 hours ago|
|db||22 hours ago|
|docs||23 hours ago|
|gctest||22 hours ago|
|handlers||22 hours ago|
|pack||22 hours ago|
|public||2 days ago|
|tpl||23 hours ago|
|.editorconfig||1 month ago|
|.gitattributes||1 month ago|
|.gitignore||2 weeks ago|
|.gogo-release||2 months ago|
|.ignore||5 months ago|
|.travis.yml||2 weeks ago|
|CHANGELOG.markdown||1 week ago|
|LICENSE||1 month ago|
|README.markdown||2 weeks ago|
|admin.go||2 weeks ago|
|blacklist.go||1 month ago|
|flag.go||1 month ago|
|flag_test.go||1 month ago|
|gen.go||1 month ago|
|go.mod||22 hours ago|
|go.sum||22 hours ago|
|helper.go||2 weeks ago|
|hit.go||22 hours ago|
|hit_test.go||23 hours ago|
|memstore.go||23 hours ago|
|memstore_test.go||22 hours ago|
|netlify.toml||2 months ago|
|session.go||22 hours ago|
|site.go||1 week ago|
|site_test.go||2 weeks ago|
|tplfunc.go||1 week ago|
|update.go||1 month ago|
|user.go||2 weeks ago|
GoatCounter is a web analytics platform, roughly similar to Google Analytics or Matomo. It aims to give meaningful privacy-friendly web analytics for business purposes, while still staying usable for non-technical users to use on personal websites. The choices that currently exist are between freely hosted but with problematic privacy (e.g. Google Analytics), hosting your own complex software or paying $19/month (e.g. Matomo), or extremely simplistic “vanity statistics”.
There are two ways to run this: as hosted service on goatcounter.com, free for non-commercial use, or run it on your own server.
See docs/rationale.markdown for some more details on the “why?” of this project.
There’s a live demo at https://stats.arp242.net.
Please consider contributing financially if you’re self-hosting GoatCounter so I can pay my rent :-)
Easy; if you’ve been confused by the myriad of options and flexibility of Google Analytics and Matomo that you don’t need then GoatCounter will be a breath of fresh air.
100% committed to open source; you can see exactly what the code does and make improvements.
Own your data; you can always export all data and cancel at any time.
Integrate on your site with just a single script tag:
Fast: can handle about 800 hits/second on a $5/month Linode VPS using the default settings.
Self-contained binary: everything – including static assets – is in a single ~7M statically compiled binary. The only other thing you need is a SQLite database file or PostgreSQL connection (no way around that).
Compile from source with:
$ git clone https://github.com/zgoat/goatcounter.git $ cd goatcounter $ go build ./cmd/goatcounter
You’ll now have a
goatcounter binary in the current directory.
The master branch should be reasonably stable. You can get a specific release by
checking out the branch for the latest version:
git checkout v1.1.0.
It’s not recommended to use
go get in GOPATH mode since that will ignore the
dependency versions in go.mod.
Go 1.13 and newer are supported (it follows the Go release policy). You will need a C compiler (for SQLite) or PostgreSQL.
You can start the server with:
goatcounter serve -dev
The default is to use a SQLite database at
./db/goatcounter.sqlite3 (will be
created if it doesn’t exist). See the
-db flag to customize this.
You can create new sites with the
goatcounter create -email email@example.com -domain stats.example.com
If you use a custom DB, you must also pass the
-db flag here.
-dev flag makes some small things a bit more convenient for development,
such as logins. For a production environment run something like:
Using an SMTP relay via
-smtp isn’t required, but will usually guarantee
better deliverability, so is recommended (delivering emails without them ending
up in the spambox is hard). You should be able to use your
gmail/FastMail/ProtonMail/etc. account for this.
You may need to run run database migrations when updating. Use
-automigrate to always run all pending migrations on startup. This is the
easiest way, although arguably not the “best” way.
goatcounter migrate <file> or
goatcounter migrate all to manually run
migrations; generally you want to upload the new version, run migrations while
the old one is still running, and then restart so the new version takes effect.
goatcounter migrate show to get a list of pending migrations.
Both SQLite and PostgreSQL are supported. SQLite should work well for the vast majority of people and is the recommended database engine. PostgreSQL will not be faster in most cases, and the chief reason for adding support in the first place is to support load balancing web requests over multiple servers. To use it:
Create the database, unlike SQLite it’s not done automatically (you may need
to modify the
$ createdb goatcounter $ psql goatcounter -c ‘\i db/schema.pgsql’ $ goatcounter -db ‘postgresql://dbname=goatcounter’ migrate all
Run with custom
$ goatcounter serve
-db 'postgresql://user=goatcounter dbname=goatcounter sslmode=disable'
See the pq docs for more details on the connection string.
You can compile goatcounter without cgo if you don’t use SQLite:
$ CGO_ENABLED=0 go build
Functionally it doesn’t matter too much, but builds will be a bit easier and faster as it won’t require a C compiler.
See .github/CONTRIBUTING.markdown for details on how to run a development server, write patches, etc.